目录
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 也能拿到 B
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 尝试获取 B, 并没有释放 A
synchronized (B) {
System.out.println("t1 拿到了两把锁!");
}
}
});
Thread t2 = new Thread(() -> {
synchronized (A) {
// sleep一下, 给 t1 时间, 让 t1 能拿到 A
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 尝试获取 A, 并没有释放 B
synchronized (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、解决死锁问题
要想解决死锁情况,就得先讨论产生死锁的原因:
死锁产生的四个必要条件(缺一不可)
由于是必要条件,只需要破坏其中一种条件,就可以让死锁解开。
- 互斥使用。一个线程拿到了这把锁,另一个线程也想获取,就需要阻塞等待,这是锁最基本的特性,不好破坏。
- 不可抢占。一个线程拿到了锁之后,只能主动解锁,不能让别的线程强行把锁抢走,这也是锁最基本的特性,不好破坏。
- 请求保持。一个线程拿到了锁A,在持有锁A的前提下,尝试获取锁B。这些场景下必须需要这样使用,也不好破坏。
- 循环等待/环路等待,是一种代码结构,是最容易破坏。
由上述分析可以得知,想要解决死锁问题,要从破坏循环等待/环路等待入手。
引入加锁顺序的规则就是很好破解循环等待的办法,即给每一个锁编号,规定只能按照锁的序号顺序拿起,就能打破循环等待。
举例说明:
依然是是上面的哲学家就餐问题,此时给筷子编号序号之后,要求只能按照顺序由小到大拿起,此时就算是所有人同时拿起筷子,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
如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!
如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!
如果觉得作者写的不错,求给博主一个大大的点赞支持一下,你们的支持是我更新的最大动力!