目录

1、线程加锁

2、死锁问题的三种经典场景

2.1、一个线程一把锁

2.2、两个线程两把锁

2.3、N个线程M把锁(哲学家就餐问题)

3、解决死锁问题

1、线程加锁

其中 locker 可以是任意对象,进入 synchronized 修饰的代码块, 相当于加锁,退出 synchronized 修饰的代码块, 相当解锁。

如果一个线程,针对一个对象加上锁之后,其他线程也尝试对这个对象加锁,就会导致锁竞争进而引起阻塞(BLOCKED),这个阻塞会一直持续到上一个线程释放锁为止。

如果是两个线程分别针对不同的对象进行加锁,此时不会由锁竞争,也就不会阻塞。

出现锁竞争进而引起阻塞状态,这个阻塞会一直持续到下一个线程释放锁为止。

但是,设想一个场景,共有AB两个线程,此时A线程因为锁竞争进入阻塞状态,而如果此时B线程恰巧也正在阻塞状态,由于AB线程都进入了阻塞状态,此时进程无法运行,出现死锁问题。下面针对死锁问题的出现以及解决方法展开讨论。

2、死锁问题的三种经典场景

2.1、一个线程一把锁

public static void main(String[] args) {Object locker = new Object();Thread t = new Thread(() -> {synchronized (locker) { //两次加锁,加的是同一把锁synchronized (locker) { //两次加锁,加的是同一把锁System.out.println("hello synchronized");}}});t.start();}

需要注意的是,这里最直观的感觉是进行了两次加锁,会发生锁冲突。第一次针对locker加锁之后,在还没释放锁的时候又尝试对locker加锁,理论会出现锁冲突。

至于事实上是否会出现所冲突进而出现死锁,需要分情况讨论:

1、如果是不可重入锁,则就会出现锁竞争引起死锁。

2、如果是可重入锁,则不会出现锁竞争引起死锁,Java中的锁就是可重入锁,因此可以正常打印。

可以把这种情况理解成:【屋钥匙锁在了屋里】

2.2、两个线程两把锁

package thread;public class ThreadDemo22 {public static void main(String[] args) {Object A = new Object();Object B = new Object();Thread t1 = new Thread(() -> {synchronized (A) {// sleep一下, 给 t2 时间, 让 t2 也能拿到 Btry {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}// 尝试获取 B, 并没有释放 Asynchronized (B) {System.out.println("t1 拿到了两把锁!");}}});Thread t2 = new Thread(() -> {synchronized (A) {// sleep一下, 给 t1 时间, 让 t1 能拿到 Atry {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}// 尝试获取 A, 并没有释放 Bsynchronized (B) {System.out.println("t2 拿到了两把锁!");}}});t1.start();t2.start();}}

两个线程,两把锁。线程A获取到锁A,线程B获取到锁B,在没释放锁AB的前提下,线程A尝试获取锁B,线程B尝试获取锁A,就会出现死锁。

可以把这种情况理解成:【屋钥匙锁在了车里,车钥匙锁在了屋里】

2.3、N个线程M把锁(哲学家就餐问题)

首先假设一个场景,一张圆桌上坐着五个人,每个人面前都有一碗面条,桌子上一共有五根筷子(不是五双),而将五根筷子分别摆放在两人各自之间,如下图。

要想吃面条,需要拿起自己身旁的两根筷子(左右两根,只能拿身边的这两根)。假设此时A拿起了左右筷子吃面条,此时B就无法吃,因为A正在使用B的左筷子,B目前只能拿起一根右筷子,并且开始等待,等待A放下筷子,再拿起左筷子吃面条(此处的等待只有拿到另外一根筷子后才会停止,并且等待的同时不会放下已经拿起的筷子)。同理E也一样。

此处讨论的问题中N等于M。我们将线程比作人筷子比作锁此时B所处的状态可以比作锁竞争引起的阻塞状态。大家可以试着想想各种其他不同的情况,始终都能保证桌上5个人至少有一人正在吃面条,除了一种特殊的极端情况下:

极端情况下,会出现所有人同时都拿了同一侧的筷子(例如都拿了左筷子),导致所有人都不能拿起另一侧的筷子而都进入阻塞,等待着别人放下筷子后自己再拿起来。但是此时又因为没有一个人能吃的上面条,因此永远不会有人放下筷子,出现死锁。

这个问题也被人称之为:哲学家就餐问题。

3、解决死锁问题

要想解决死锁情况,就得先讨论产生死锁的原因:

死锁产生的四个必要条件(缺一不可)

由于是必要条件,只需要破坏其中一种条件,就可以让死锁解开。

  1. 互斥使用。一个线程拿到了这把锁,另一个线程也想获取,就需要阻塞等待,这是锁最基本的特性,不好破坏。
  2. 不可抢占。一个线程拿到了锁之后,只能主动解锁,不能让别的线程强行把锁抢走,这也是锁最基本的特性,不好破坏。
  3. 请求保持。一个线程拿到了锁A,在持有锁A的前提下,尝试获取锁B。这些场景下必须需要这样使用,也不好破坏。
  4. 循环等待/环路等待,是一种代码结构,是最容易破坏。

由上述分析可以得知,想要解决死锁问题,要从破坏循环等待/环路等待入手。

引入加锁顺序的规则就是很好破解循环等待的办法,即给每一个锁编号,规定只能按照锁的序号顺序拿起,就能打破循环等待。

举例说明:

依然是是上面的哲学家就餐问题,此时给筷子编号序号之后,要求只能按照顺序由小到大拿起,此时就算是所有人同时拿起筷子,C先拿1,B先拿2,A先拿3,E先拿4,此时D按照规定应该拿起1,但是此时C正拿着1,因此此时D还没有机会拿起5,就直接进入阻塞状态。此场景下E就能拿起5开始吃面,E放下筷子A就接着吃,依此类推,就将可能出现的死锁问题破解了。

【博主推荐】

【Java多线程】线程中几个常见的属性以及状态-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136122127?spm=1001.2014.3001.5501【Java多线程】Thread类的基本用法-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136121421?spm=1001.2014.3001.5501【Java多线程】对进程与线程的理解-CSDN博客https://blog.csdn.net/zzzzzhxxx/article/details/136115808?spm=1001.2014.3001.5501

如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!

如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!

如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!