死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象。若无外力作用,它们都将无法推进下去。
目前创新互联已为上1000家的企业提供了网站建设、域名、网页空间、网站托管、服务器托管、企业网站设计、遂溪网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。
产生死锁的四个必要条件得烂熟于心:
相应的,如果想在程序运行之前预防发生死锁(也成为 “死锁预防”),必须设法破坏产生死锁的四个必要条件之一
光看罗列出来的几点文字肯定还是不能完全理解,下面会结合实例来给大伙解释。
用 Java 写一个死锁
这绝对是面试中 Java 手写题的 TOP2!!!除了人尽皆知的手写单例模式,手写死锁可能有些小伙伴会遗漏掉。
逻辑其实非常简单,我们申请两个资源,开两个线程,每个线程持有其中的一个资源,并且互相请求对方的资源,就构成了死锁。
MySQL 经典的死锁案例
下面来看个 MySQL 经典的死锁案例:转账
A 账户给 B 账户转账 50 元的同时,B 账户也给 A 账户转账 30 元
正常情况下,如果只有一个操作,A 给 B 转账 50 元,可以在一个事务内完成,先获取 A 用户的余额和 B 用户的余额,因为之后需要修改这两条数据,所以需要通过写锁(for UPDATE)锁住他们,防止其他事务更改导致我们的更改丢失而引起脏数据
但如果 A 给 B 转账和 B 给 A 转账同时发生,那就是两个事务,可能发生死锁:
1)A 用户给 B 用户转账 50 元,需在程序中开启事务 1 来执行 SQL,获取 A 的余额同时锁住 A 这条数据。
2)B 用户给 A 用户转账 30 元,需在程序中开启事务 2 来执行 SQL,并获取 B 的余额同时锁住 B 这条数据。
3)在事务 1 中执行剩下的 SQL,此时事务 1 是获取不到 B 的锁的,也即 select for update 就会被阻塞住;
4)同理,事务 2 继续执行剩下的 SQL,请求 A 的锁,也是获取不到的
事务 1 和事务 2 存在相互等待获取锁的过程,导致两个事务都挂起阻塞,最终抛出获取锁超时的异常。
要想解决上述死锁问题,我们可以从死锁的四个必要条件入手。
指导思想其实很明确:就是保证 A 向 B 转账和 B 向 A 转账这两个事务同一时刻只能有一个事务能成功获取到锁
由于互斥和不剥夺是锁本质的功能体现,无法修改,所以咱们从另外两个条件尝试去解决。
1)破坏 “请求和保持” 条件:A 和 B 之间的操作用同一个锁锁住(比如用 Redis 分布式锁做,A 和 B 之间的锁的 key 表示为 A:B,可以让 id 小的用户排在前面,id 大的用户排在后面,这样来设计 key。如果存在分库分表的情况,用 hashcode 来做比较也行),保证 A 向 B 转账和 B 向 A 转账这两个事务同一时刻只能有一个事务能成功获取锁
2)破坏 “循环等待” 条件:先获取更小的锁,获取到了小的锁才能获取大锁(所谓小锁还是大锁,也可以简单的根据用户的 id 来进行区分,先请求用户 id 较小的,再请求用户 id 较大的)。比如 A.id < B.id,那么 A 和 B 之间的操作,都是要先获取 A 锁,再获取 B 锁
具体代码可参考如下:
网页题目:关于死锁,面试的一切都在这里了
当前链接:http://www.gawzjz.com/qtweb2/news26/9526.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联