欢迎来到《并发王者课》,本文是黄金互该系列文章中的第11篇。
在本篇文章中,我将为你介绍多线程中的两败经典问题-死锁,以及死锁的产生原因 、处理和方式预防措施 。俱伤僵局
观察下面这幅图,线程1持有了A,但它需要B;而线程2持有了B,但是相让它需要A。
你看,问题就来了,A 、线导B都在等待对方已经持有的程何资源,并且都不释放,这就让事情陷入了僵局,也就是产生了死锁。
在并发编程中,死锁表示的死锁是一种状态。在这种状态下,各方都在等待另一方释放所持有的黄金互资源,但是它们之间又缺乏必要的通信机制,导致彼此存在环路依赖而永远地等待下去。
死锁不仅存在于Java程序中,在诸如数据库等其他中间件及分布式架构中都会存在。两败在数据的俱伤僵局设计中,会考虑到死锁的监测和恢复。当数据库中发生死锁时,将选择一个牺牲者并放弃对应的相让事务,同时释放锁定的资源。在它的线导竞争者执行结束后,应用程序可以重新运行这个事务,因为它的竞争者此前已经完成事务 。
然而,在JVM中,处理死锁并没有数据库中那么优雅 。程何当一组线程发生死锁时,“游戏”将到此结束,这些线程将不能再使用,而这可能会直接导致应用程序崩溃 、死锁性能降低或者部分功能停止 。黄金互
所以,和其他并发问题一样,死锁是危险的,死锁造成的影响会立即表现出来,而如果在高负载情况下,这将是一场灾难。
从第一小节的图示中,我们可以看到死锁产生的一些必要条件:
在了解什么是死锁及其产生的条件后,我们根据上图中的死锁情景,通过一段代码来模拟体验死锁的发生 。
根据上图所示,定义哪吒线程,在运行时将持有A并请求B:
定义兰陵王线程,在运行时持有B并请求A:
启动两个线程:
两个线程的输出结果如下:
从结果中可以看到,哪吒和兰陵王分别持有了A和B,但他们又相互请求对方持有的资源,最终导致死锁,两个线程进入了无限地等待 。
忽略死锁是一种鸵鸟政策,它假设永远不会发生死锁。这种策略适用于死锁发生概率较低且影响可容忍的场景,如果死锁被证明永远不会发生也可以采用这种策略。
在这种策略下,死锁是允许发生的。如果系统检测到死锁,也会对其进行纠正,比如跟踪线程状态和资源分配。在死锁时,可以通过一些方法进行纠正:
对待死锁问题,预防是关键。本文第二小节已经列举死锁产生的一些必要条件,所以如果要预防死锁,只要打破其中任一条件即可,Java中具体的死锁预发方式我们会在后面的文章中介绍 。
以上就是关于死锁的全部内容。在本文中,我们介绍了什么是死锁,以及死锁产生的必要条件和应对策略。对待开发中的死锁问题,既要保持敬畏之心,也不必闻之色变,审慎分析死锁的可能并设计合理策略可以有效预防死锁 。
正文到此结束,恭喜你又上了一颗星✨
夫子的试炼
延伸阅读与参考资料
关于作者
关注公众号【庸人技术笑谈】,获取及时文章更新 。记录平凡人的技术故事,分享有品质(尽量)的技术文章,偶尔也聊聊生活和理想。不贩卖焦虑,不做标题党。
如果本文对你有帮助,欢迎点赞 、关注、监督,我们一起从青铜到王者。