java 死锁及解决

时间 2019-11-24

标签 java 死锁解决栏目 Java 繁體版

原文原文链接

Java线程死锁如何避免这一悲剧 Java线程死锁须要如何解决，这个问题一直在咱们不断的使用中须要只有不断的关键。不幸的是，使用上锁会带来其余问题。让咱们来看一些常见问题以及相应的解决方法：html

　　Java线程死锁java

　　Java线程死锁是一个经典的多线程问题，由于不一样的线程都在等待那些根本不可能被释放的锁，从而致使全部的工做都没法完成。假设有两个线程，分别表明两个饥饿的人，他们必须共享刀叉并轮流吃饭。他们都须要得到两个锁：共享刀和共享叉的锁。编程

　　假如线程 “A”得到了刀，而线程“B”得到了叉。线程“A”就会进入阻塞状态来等待得到叉，而线程“B”则阻塞来等待“A”所拥有的刀。这只是人为设计的例子，但尽管在运行时很难探测到，这类状况却时常发生。虽然要探测或推敲各类状况是很是困难的，但只要按照下面几条规则去设计系统，就可以避免Java线程死锁问题：安全

　　让全部的线程按照一样的顺序得到一组锁。这种方法消除了 X 和 Y 的拥有者分别等待对方的资源的问题。多线程

　　将多个锁组成一组并放到同一个锁下。前面Java线程死锁的例子中，能够建立一个银器对象的锁。因而在得到刀或叉以前都必须得到这个银器的锁。并发

　　将那些不会阻塞的可得到资源用变量标志出来。当某个线程得到银器对象的锁时，就能够经过检查变量来判断是否整个银器集合中的对象锁均可得到。若是是，它就能够得到相关的锁，不然，就要释放掉银器这个锁并稍后再尝试。app

　　最重要的是，在编写代码前认真仔细地设计整个系统。多线程是困难的，在开始编程以前详细设计系统可以帮助你避免难以发现Java线程死锁的问题。svn

　　Volatile 变量，volatile 关键字是 Java 语言为优化编译器设计的。如下面的代码为例：工具

　　1.class VolatileTest {测试

　　2.public void foo() {

　　3.boolean flag = false;

　　4.if(flag) {

　　5.//this could happen

　　6.}

　　7.}

　　8.}

　　一个优化的编译器可能会判断出if部分的语句永远不会被执行，就根本不会编译这部分的代码。若是这个类被多线程访问， flag被前面某个线程设置以后，在它被if语句测试以前，能够被其余线程从新设置。用volatile关键字来声明变量，就能够告诉编译器在编译的时候，不须要经过预测变量值来优化这部分的代码。

　　没法访问的Java线程死锁有时候虽然获取对象锁没有问题，线程依然有可能进入阻塞状态。在 Java 编程中IO就是这类问题最好的例子。当线程由于对象内的IO调用而阻塞时，此对象应当仍能被其余线程访问。该对象一般有责任取消这个阻塞的IO操做。形成阻塞调用的线程经常会令同步任务失败。若是该对象的其余方法也是同步的，当线程被阻塞时，此对象也就至关于被冷冻住了。

　　其余的线程因为不能得到对象的Java线程死锁，就不能给此对象发消息（例如，取消 IO 操做）。必须确保不在同步代码中包含那些阻塞调用，或确认在一个用同步阻塞代码的对象中存在非同步方法。尽管这种方法须要花费一些注意力来保证结果代码安全运行，但它容许在拥有对象的线程发生阻塞后，该对象仍可以响应其余线程。

=======================================================================

死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者所有都在等待某个资源被释放。因为线程被无限期地阻塞，所以程序不可能正常终止。

致使死锁的根源在于不适当地运用“synchronized”关键词来管理线程对特定对象的访问。“synchronized”关键词的做用是，确保在某个时刻只有一个线程被容许执行特定的代码块，所以，被容许执行的线程首先必须拥有对变量或对象的排他性的访问权。当线程访问对象时，线程会给对象加锁，而这个锁致使其它也想访问同一对象的线程被阻塞，直至第一个线程释放它加在对象上的锁。

因为这个缘由，在使用“synchronized”关键词时，很容易出现两个线程互相等待对方作出某个动做的情形。代码一是一个致使死锁的简单例子。

//代码一

Java代码

class Deadlocker {
int field_1;
private Object lock_1 = new int[1];
int field_2;
private Object lock_2 = new int[1];
public void method1(int value) {
“synchronized” (lock_1) {
“synchronized” (lock_2) {
field_1 = 0; field_2 = 0;
}
}
}
public void method2(int value) {
“synchronized” (lock_2) {
“synchronized” (lock_1) {
field_1 = 0; field_2 = 0;
}
}
}
}

Java代码

class Deadlocker {
int field_1;
private Object lock_1 = new int[1];
int field_2;
private Object lock_2 = new int[1];
public void method1(int value) {
“synchronized” (lock_1) {
“synchronized” (lock_2) {
field_1 = 0; field_2 = 0;
}
}
}
public void method2(int value) {
“synchronized” (lock_2) {
“synchronized” (lock_1) {
field_1 = 0; field_2 = 0;
}
}
}
}

class Deadlocker {
 int field_1;
 private Object lock_1 = new int[1];
 int field_2;
 private Object lock_2 = new int[1];

 public void method1(int value) {
  “synchronized” (lock_1) {
   “synchronized” (lock_2) {
    field_1 = 0; field_2 = 0;
   }
  }
 }

 public void method2(int value) {
  “synchronized” (lock_2) {
   “synchronized” (lock_1) {
    field_1 = 0; field_2 = 0;
   }
  }
 }
}

参考代码一，考虑下面的过程：

◆ 一个线程（ThreadA）调用method1()。

◆ ThreadA在lock_1上同步，但容许被抢先执行。

◆ 另外一个线程（ThreadB）开始执行。

◆ ThreadB调用method2()。

◆ ThreadB得到lock_2，继续执行，企图得到lock_1。但ThreadB不能得到lock_1，由于ThreadA占有lock_1。

◆ 如今，ThreadB阻塞，由于它在等待ThreadA释放lock_1。

◆ 如今轮到ThreadA继续执行。ThreadA试图得到lock_2，但不能成功，由于lock_2已经被ThreadB占有了。

◆ ThreadA和ThreadB都被阻塞，程序死锁。

固然，大多数的死锁不会这么显而易见，须要仔细分析代码才能看出，对于规模较大的多线程程序来讲尤为如此。好的线程分析工具，例如JProbe Threadalyzer可以分析死锁并指出产生问题的代码位置。

隐性死锁

隐性死锁因为不规范的编程方式引发，但不必定每次测试运行时都会出现程序死锁的情形。因为这个缘由，一些隐性死锁可能要到应用正式发布以后才会被发现，所以它的危害性比普通死锁更大。下面介绍两种致使隐性死锁的状况：加锁次序和占有并等待。

加锁次序

当多个并发的线程分别试图同时占有两个锁时，会出现加锁次序冲突的情形。若是一个线程占有了另外一个线程必需的锁，就有可能出现死锁。考虑下面的情形，ThreadA和ThreadB两个线程分别须要同时拥有lock_一、lock_2两个锁，加锁过程可能以下：

◆ ThreadA得到lock_1；

◆ ThreadA被抢占，VM调度程序转到ThreadB；

◆ ThreadB得到lock_2；

◆ ThreadB被抢占，VM调度程序转到ThreadA；

◆ ThreadA试图得到lock_2，但lock_2被ThreadB占有，因此ThreadA阻塞；

◆ 调度程序转到ThreadB；

◆ ThreadB试图得到lock_1，但lock_1被ThreadA占有，因此ThreadB阻塞；

◆ ThreadA和ThreadB死锁。

必须指出的是，在代码丝绝不作变更的状况下，有些时候上述死锁过程不会出现，VM调度程序可能让其中一个线程同时得到lock_1和lock_2两个锁，即线程获取两个锁的过程没有被中断。在这种情形下，常规的死锁检测很难肯定错误所在。

占有并等待

若是一个线程得到了一个锁以后还要等待来自另外一个线程的通知，可能出现另外一种隐性死锁，考虑代码二。

//代码二

Java代码

public class queue {
static java.lang.Object queueLock_;
Producer producer_;
Consumer consumer_;
public class Producer {
void produce() {
while (!done) {
“synchronized” (queueLock_) {
produceItemAndAddItToQueue();
“synchronized” (consumer_) {
consumer_.notify();
}
}
}
}
public class Consumer {
consume() {
while (!done) {
“synchronized” (queueLock_) {
“synchronized” (consumer_) {
consumer_.wait();
}
removeItemFromQueueAndProcessIt();
}
}
}
}
}
}

Java代码

public class queue {
static java.lang.Object queueLock_;
Producer producer_;
Consumer consumer_;
public class Producer {
void produce() {
while (!done) {
“synchronized” (queueLock_) {
produceItemAndAddItToQueue();
“synchronized” (consumer_) {
consumer_.notify();
}
}
}
}
public class Consumer {
consume() {
while (!done) {
“synchronized” (queueLock_) {
“synchronized” (consumer_) {
consumer_.wait();
}
removeItemFromQueueAndProcessIt();
}
}
}
}
}
}

public class queue {
 static java.lang.Object queueLock_;
 Producer producer_;
 Consumer consumer_;

 public class Producer {
  void produce() {
   while (!done) {
    “synchronized” (queueLock_) {
     produceItemAndAddItToQueue();
     “synchronized” (consumer_) {
      consumer_.notify();
     }
    }
   }
  }

  public class Consumer {
   consume() {
    while (!done) {
     “synchronized” (queueLock_) {
      “synchronized” (consumer_) {
       consumer_.wait();
      }
      removeItemFromQueueAndProcessIt();
     }
    }
   }
  }
 }
}

在代码二中，Producer向队列加入一项新的内容后通知Consumer，以便它处理新的内容。问题在于，Consumer可能保持加在队列上的锁，阻止Producer访问队列，甚至在Consumer等待Producer的通知时也会继续保持锁。这样，因为Producer不能向队列添加新的内容，而Consumer却在等待Producer加入新内容的通知，结果就致使了死锁。

在等待时占有的锁是一种隐性的死锁，这是由于事情可能按照比较理想的状况发展—Producer线程不须要被Consumer占据的锁。尽管如此，除非有绝对可靠的理由确定Producer线程永远不须要该锁，不然这种编程方式还是不安全的。有时“占有并等待”还可能引起一连串的线程等待，例如，线程A占有线程B须要的锁并等待，而线程B又占有线程C须要的锁并等待等。

要改正代码二的错误，只需修改Consumer类，把wait()移出“synchronized”()便可。

所以避免死锁的一个通用的经验法则是:当几个线程都要访问共享资源A、B、C时，保证使每一个线程都按照一样的顺序去访问它们，好比都先访问A，在访问B和C。此外，Thread类的suspend()方法也很容易致使死锁,所以这个方法已经被废弃了.