面试：“必然”引起“死锁”的一段代码。

这个必然让我有点疑惑，A 等待 B，B 等待 A 这种还有意外会发生吗？求教。

大家可以看一下#15 @ryd994 还有 #13 @geelaw 还有 #20 @mashiro233 这几位朋友的回答，再次感谢大家。 ----------------------- 以下是精选回复-----------------------

答:建议多翻一下《操作系统》和语文书。
答:分分钟 100 个例子
答:数据库里面很多，代码倒是没咋接触过
答:老哥看一下 实战 Java 高并发程序设计 4.5 有关死锁的问题 那一章节
百分百死锁啊, 讲的还是挺详细的.
这里贴代码排版会有问题, 老哥你可以直接去看一下书
答:这个是肯定会引起死锁的，这种情况在多节点的 RAC 上见得比较多，比如需要同时更新多个表时，不同的业务对这几张表的更新顺序不一致，就容易引发死锁。

不过像 Oracl 这样企业级的软件都会有自动的解锁行为，有个时间阈值，超过后就会牺牲掉一个事物，达到解锁目的。所以实际业务中几乎不会出现长时间的死锁。
答:死锁的四个必要条件
答:是不是我语文不好，看不懂楼主想表达什么
答:methodA() {
synchronized(lockA) {
Thread.sleep(10000);
synchronized(lockB) {
...
}
}
}

methodB() {
synchronized(lockB) {
Thread.sleep(10000);
synchronized(lockA) {
...
}
}
}

拿去不谢
答:对方是某一线大厂资深级别的技术 leader，感觉事情并不简单，所以才会来 V 站一问，下午我会更新一下结果。
答:线程 1:
锁 A
锁 B
干活
释放 B
释放 A

线程 2:
锁 B
锁 A
干活
释放 A
释放 B

这样就会死锁啊
答:用睡眠并不会必然导致死锁，只是以非常高的概率导致而已。

一个简单的方法是这样：线程 1 把自己的 handle 存在全局变量的 1 里，然后启动线程 2 并获得其 handle，然后等待这个 handle （等线程 2 结束）；线程 2 的惟一工作是等待线程 1 的 handle。很容易证明，无论怎样调度，一定会进入死锁。

在没有单进程多线程概念的操作系统（如传统 UNIX ），你需要通过进程的等待完成类似任务。
答:非重入锁重入就是保证死锁
答:写个哲学家就餐问题不就 ok 了。。。
答:哲学家就餐 加一
答:thread 1:
acquire(A)
acquire(B)

thread 2:
acquire(B)
acquire(A)

Bomb !!!
答:楼上的一些朋友回答的很好了。
调度器的运作原理对应用层来说应该是未定义的。代码中启动 A,B 两个线程，调度器可以不保证 A 在 B 之前或者之后启动，启动了也不保证每个线程能用多少 cpu 时间。
答:iOS 中 OSSpinLock 优先级反转也会死锁
答:互斥
不可剥夺
请求和保持
循环等待
答:必然死锁，一个线程内才行，连续多次试锁同一资源？多个线程就不是必然
答:线程 A：
l1.lock()
while(true)
l2.lock()

线程 B：
l2.lock()
while(true)
l1.lock()
答:l1 = lock()
l1.lock()
l1.lock()

这不就死锁了。
答:上了一课
答:对，这不是考 OS，这是靠分布式系统与算法
答:邮局寄个包裹给你, 要你身份证就能给你,但你的身份证就在包裹里~ 所以死锁了~