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

[1cming]

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

[hxd]

建议多翻一下《操作系统》和语文书。

[zhengxiaowai]

分分钟 100 个例子

[luojianxhlxt]

数据库里面很多，代码倒是没咋接触过

[Arsenal16]

老哥看一下 实战 Java 高并发程序设计 4.5 有关死锁的问题 那一章节
百分百死锁啊, 讲的还是挺详细的.
这里贴代码排版会有问题, 老哥你可以直接去看一下书

[ldd]

这个是肯定会引起死锁的，这种情况在多节点的 RAC 上见得比较多，比如需要同时更新多个表时，不同的业务对这几张表的更新顺序不一致，就容易引发死锁。

不过像 Oracl 这样企业级的软件都会有自动的解锁行为，有个时间阈值，超过后就会牺牲掉一个事物，达到解锁目的。所以实际业务中几乎不会出现长时间的死锁。

[q397064399]

死锁的四个必要条件

[0Y89tX3MgR4I]

是不是我语文不好，看不懂楼主想表达什么

[1cming]

@Arsenal16 好的谢谢我下午看一下

[GuuJiang]

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

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

拿去不谢

[1cming]

@Arsenal16 这里我刚才看了 他举的例子也并没有特别的地方 难道是我多想了？


@hxd
@zhengxiaowai
@ldd
@0Y89tX3MgR4I
对方的原话大意是：写一个“必然”会出现死锁的一段代码，我面过很多人，他们写的都不是严格意义上的死锁，都被我挑出来很多刺。
鉴于此，我在思考是否有代码之外比如 OS 上的一些考虑？

[1cming]

对方是某一线大厂资深级别的技术 leader，感觉事情并不简单，所以才会来 V 站一问，下午我会更新一下结果。

[startar]

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

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

这样就会死锁啊

[geelaw]

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

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

在没有单进程多线程概念的操作系统（如传统 UNIX ），你需要通过进程的等待完成类似任务。

[ryd994]

非重入锁重入就是保证死锁

[ryd994]

多线程的话可以用信号量
1 锁 A，2 锁 B
1 给 2 发信号，2 给 1 发信号
等到收到信号，1 锁 B，2 锁 A
因为各自没有取得锁前不会发出信号，因此收到信号就可以保证死锁
信号量可以使用操作系统的信号量，也可以使用原子变量简单实现

这不是一道考锁的题，而是一道考分布式系统事件排序的题

@GuuJiang 如果因为进程调度，method B 被调度到 A 完成之后才执行呢？正常调度系统会考虑公平性，所以很难发生。但这并不是前提条件。

[roychan]

写个哲学家就餐问题不就 ok 了。。。

[John60676]

哲学家就餐 加一

[0Y89tX3MgR4I]

@ryd994 嗯，两个锁和一个条件变量就好了

[nullcc]

thread 1:
acquire(A)
acquire(B)

thread 2:
acquire(B)
acquire(A)

Bomb !!!

[mashiro233]

楼上的一些朋友回答的很好了。
调度器的运作原理对应用层来说应该是未定义的。代码中启动 A,B 两个线程，调度器可以不保证 A 在 B 之前或者之后启动，启动了也不保证每个线程能用多少 cpu 时间。