1

手画图解,关于死锁,面试的一切都在这里了 - 飞天小牛肉

 1 year ago
source link: https://www.cnblogs.com/cswiki/p/16981418.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

什么是死锁(Deadlock)

死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象。若无外力作用,它们都将无法推进下去。

image-20221127104906701.png

产生死锁的四个必要条件得烂熟于心:

  • 互斥条件:进程要求对所分配的资源进行排他性控制,即在一段时间内某资源仅为一个进程所占用。此时若有其他进程请求该资源,则请求进程只能等待。
  • 不剥夺条件:进程所获得的资源在未使用完毕之前,不能被其他进程强行夺走,即只能由获得该资源的进程自己来释放。
  • 请求和保持条件:进程已经保持了至少一个资源,但又提出了新的资源请求,而该资源已被其他进程占有,此时请求进程被阻塞,但对自己已获得的资源保持不放。
  • 循环等待条件:存在一种进程资源的循环等待链,连中每一个进程已获得的资源同时被链中下一个进程所请求。

相应的,如果想在程序运行之前预防发生死锁(也成为 “死锁预防”),必须设法破坏产生死锁的四个必要条件之一

  • 破坏互斥条件:允许系统资源都能共享使用,则系统不会进行死锁状态。这种方案并不太可行,因为有些资源根本就不能同时访问,比如打印机。
  • 破坏不剥夺条件:当一个已经保持了某些不可剥夺资源的进程,请求新的资源时得不到满足,它必须释放已经保持的所有资源,待以后需要时再重新申请。这种方法常用于状态易于保存和恢复的资源,如 CPU 的寄存器及内存资源,一般不能用于打印机之类的资源。
  • 破坏请求和保持条件:采用预先静态分配方法,即进程在运行前一次申请完他所需要的全部资源,在他的资源未满足前,不把它投入运行。一旦运行后,这些资源就一直归它所有,也不再提出其他资源请求,这样就可以保证系统不会发生死锁。
  • 破坏循环等待条件:采用顺序资源分配法。首先给系统中的资源编号,规定每个进程,必须按编号递增的顺序请求资源,同类资源一次申请完。也就是说,只要进程提出申请分配资源,则该进程在以后的资源申请中,只能申请编号比之前大的资源。

光看罗列出来的几点文字肯定还是不能完全理解,下面会结合实例来给大伙解释。

用 Java 写一个死锁

这绝对是面试中 Java 手写题的 TOP2!!!除了人尽皆知的手写单例模式,手写死锁可能有些小伙伴会遗漏掉。

逻辑其实非常简单,我们申请两个资源,开两个线程,每个线程持有其中的一个资源,并且互相请求对方的资源,就构成了死锁。

image-20221127105554518.png

MySQL 死锁

MySQL 经典的死锁案例

下面来看个 MySQL 经典的死锁案例:转账

A 账户给 B 账户转账 50 元的同时,B 账户也给 A 账户转账 30 元

image-20221127111208281.png

正常情况下,如果只有一个操作,A 给 B 转账 50 元,可以在一个事务内完成,先获取 A 用户的余额和 B 用户的余额,因为之后需要修改这两条数据,所以需要通过写锁(for UPDATE)锁住他们,防止其他事务更改导致我们的更改丢失而引起脏数据

image-20221127114513052.png
image-20221127111223709.png

但如果 A 给 B 转账和 B 给 A 转账同时发生,那就是两个事务,可能发生死锁:

1)A 用户给 B 用户转账 50 元,需在程序中开启事务 1 来执行 SQL,获取 A 的余额同时锁住 A 这条数据。

image-20221127114528053.png

2)B 用户给 A 用户转账 30 元,需在程序中开启事务 2 来执行 SQL,并获取 B 的余额同时锁住 B 这条数据。

image-20221127114545574.png

3)在事务 1 中执行剩下的 SQL,此时事务 1 是获取不到 B 的锁的,也即 select for update 就会被阻塞住;

image-20221127114558387.png

4)同理,事务 2 继续执行剩下的 SQL,请求 A 的锁,也是获取不到的

事务 1 和事务 2 存在相互等待获取锁的过程,导致两个事务都挂起阻塞,最终抛出获取锁超时的异常。

image-20221127111926247.png

如何解决 MySQL 死锁

要想解决上述死锁问题,我们可以从死锁的四个必要条件入手。

指导思想其实很明确:就是保证 A 向 B 转账和 B 向 A 转账这两个事务同一时刻只能有一个事务能成功获取到锁

由于互斥不剥夺是锁本质的功能体现,无法修改,所以咱们从另外两个条件尝试去解决。

1)破坏 “请求和保持” 条件:A 和 B 之间的操作用同一个锁锁住(比如用 Redis 分布式锁做,A 和 B 之间的锁的 key 表示为 A:B,可以让 id 小的用户排在前面,id 大的用户排在后面,这样来设计 key。如果存在分库分表的情况,用 hashcode 来做比较也行),保证 A 向 B 转账和 B 向 A 转账这两个事务同一时刻只能有一个事务能成功获取锁

image-20221127112305319.png

2)破坏 “循环等待” 条件:先获取更小的锁,获取到了小的锁才能获取大锁(所谓小锁还是大锁,也可以简单的根据用户的 id 来进行区分,先请求用户 id 较小的,再请求用户 id 较大的)。比如 A.id < B.id,那么 A 和 B 之间的操作,都是要先获取 A 锁,再获取 B 锁

image-20221127112623346.png

具体代码可参考如下:

image-20221127113156012.png

小伙伴们大家好呀,本文首发于公众号@飞天小牛肉,阿里云 & InfoQ 签约作者,分享大厂面试原创高质量题解、原创技术干活和成长经验~)


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK