所谓死锁就是进程循环等待它方占有的资源而无限制的僵持下去的局面。
以一个简单的例子来解释:一个桥,最多可以通过一个车子,但是左右两边都来了车子,而且都上了桥,左边的车子,占用了左边的桥资源,二右边的车子,占用了右边的桥的资源。左边的车子等待右边的车子让出右边的资源,但是右边的车子却要左边的车子让出左边的资源。双方都不放弃自己所占有的资源,却都想着让对方让出自己的资源,这就会无限制的等待下去。上述的车子表示进程,桥面代表着资源,资源只能由一个进程占有,不允许两个进程同时占有,结果两个进程等不能继续执行,如果不采取其他的措施,上述两个进程的等待状况会无限制的持续下去,这就是进程的死锁。计算机系统产生死锁的根本原因就是资源有限且操作不当。
产生死锁的必要条件:
1. 互斥条件:就是一个资源同时只能有一个进程占有,不能有两个或是两个以上的占有。
2. 不可抢占条件:在一个进程所获取的资源在未使用完毕之前,资源申请者不能强行的从资源占有者手中抢夺资源。
3. 占有申请条件:进程已经占有了一个资源,但是有申请新的资源;但是新申请的资源已经被别的进程占有了,此时该进程就会阻塞,但是在获取申请的资源之前他还会一直占有已占有的那个资源。
4. 循环等待条件:存在一个循环等待序列,p1等待p2,p2等待p3,p3等待p1。形成一个进程循环等待。
上述四个条件在死锁是会同时发送,也就是只要一个必要条件不通过,则就不会产生死锁。
5. 需要有两个以上的资源(表)供进程使用.
如何避免死锁:
(1) 打破互斥条件:允许进程同时访问某些资源,但是,有的资源不允许被同时访问,就像打印机,这是由资源的本身来决定的,所以这个方法并没有什么实用的价值。
(2) 打破不可抢占的条件:就是说允许进程强行从资源的占有者那里抢夺资源。这种方法实现起来很困难,会降低性能。
(3) 打破占有申请条件:可以实现资源预先分配策略,在进程运行前一次性向系统申请他所需要的全部资源。如果进程所需的资源不能满足,则不分配任何资源,进程暂时不运行。(问题:1.在很多时候,一个进程在执行之前不可能知道它所有的全部资源,进程在执行的过程中,是动态的。2.资源利用率低。3.降低进程的并发性,因为资源有效,有加上存在浪费,能分配的所需全部资源的进程个数必然很少。)
(4) 打破循环等待条件:实行资源的有序分配策略,把资源事先分类编号,按号分配,使进程在申请,占用资源时候不能形成环路,所有进程对资源的请求必须严格按照资源号递增的顺序提出,进程占用了小号的资源,才能申请大号资源。就会形成环路。(缺点:限制进程对资源的请求,同时对系统中的所有资源合理编号也是很有困难的,增加额外的系统开销。)
上述的是排除死锁的静态策略,下面可以介绍排除死锁的动态策略。
常见的有银行家算法可以避免死锁
死锁的demo:
package com.sss;
public class MyThread implements Runnable {
int flag;
static String l1 = "1";
static String l2 = "2";
public void run() {
System.out.println(flag);
if (flag == 0) {
synchronized (l1) {
try {
Thread.sleep(500);
} catch (Exception e) {
e.printStackTrace();
}
synchronized (l2) {
System.out.println("thread-1 get obj2");
}
}
}
if (flag == 1) {
synchronized (l2) {
try {
Thread.sleep(500);
} catch (Exception e) {
e.printStackTrace();
}
synchronized (l1) {
System.out.println("thread-2 get obj1");
}
}
}
}
public static void main(String[] args) {
MyThread t1 = new MyThread();
MyThread t2 = new MyThread();
t1.flag = 1;
t2.flag = 0;
Thread thread1 = new Thread(t1);
Thread thread2 = new Thread(t2);
thread1.start();
thread2.start();
}
}
解决(避免)的三种方法
- 加锁顺序(线程按照一定的顺序加锁)
- 加锁时限(线程尝试获取锁的时候加上一定的时限,超过时限则放弃对该锁的请求,并释放自己占有的锁)
- 死锁检测
死锁检测
死锁检测是一个更好的死锁预防机制,它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。
每当一个线程获得了锁,会在线程和锁相关的数据结构中(map、graph等等)将其记下。除此之外,每当有线程请求锁,也需要记录在这个数据结构中。
当一个线程请求锁失败时,这个线程可以遍历锁的关系图看看是否有死锁发生。例如,线程A请求锁7,但是锁7这个时候被线程B持有,这时线程A就可以检查一下线程B是否已经请求了线程A当前所持有的锁。如果线程B确实有这样的请求,那么就是发生了死锁(线程A拥有锁1,请求锁7;线程B拥有锁7,请求锁1)。
当然,死锁一般要比两个线程互相持有对方的锁这种情况要复杂的多。线程A等待线程B,线程B等待线程C,线程C等待线程D,线程D又在等待线程A。线程A为了检测死锁,它需要递进地检测所有被B请求的锁。从线程B所请求的锁开始,线程A找到了线程C,然后又找到了线程D,发现线程D请求的锁被线程A自己持有着。这是它就知道发生了死锁。
下面是一幅关于四个线程(A,B,C和D)之间锁占有和请求的关系图。像这样的数据结构就可以被用来检测死锁。
那么当检测出死锁时,这些线程该做些什么呢?
一个可行的做法是释放所有锁,回退,并且等待一段随机的时间后重试。这个和简单的加锁超时类似,不一样的是只有死锁已经发生了才回退,而不会是因为加锁的请求超时了。虽然有回退和等待,但是如果有大量的线程竞争同一批锁,它们还是会重复地死锁(编者注:原因同超时类似,不能从根本上减轻竞争)。
一个更好的方案是给这些线程设置优先级,让一个(或几个)线程回退,剩下的线程就像没发生死锁一样继续保持着它们需要的锁。如果赋予这些线程的优先级是固定不变的,同一批线程总是会拥有更高的优先级。为避免这个问题,可以在死锁发生的时候设置随机的优先级。