Java并发系列番外篇——同步机制（三）
姊妹篇《Java同步机制之synchronized》
姊妹篇《Java同步机制之volatile》
指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
先来看一则新闻：
《武器贸易条约》是联合国为监管八类常规武器的国际贸易制定的共同国际标准，该条约于2013年4月2日在联合国大会上通过。2013年6月3日在纽约联合国总部开放供所有国家签署，当天签署的国家超过60个。不过，美国、中国和俄罗斯这3个安理会常任理事国当天没有签约。后来，最大武器生产和出口国美国签署该条约，但未正式批准。中国和俄罗斯还未签署这一条约。2019年4月26日，美国总统特朗普在印第安纳州举行的美国步枪协会年会上宣布，《武器贸易条约》是一个“严重误导的条约”，美国将撤销在该条约上的签字。特朗普将要求国会参议院停止该条约的批准程序，使美国退出联合国《武器贸易条约》。
其实是这样的：
美国：我等俄罗斯先签了我就签；
俄罗斯：我等中国先签我了就签；
中国：我等美国先签了我就签；
算了，不等了。因为死锁了。
代码示例
当一个线程永远的持有一个锁，并且其他线程线程都尝试获得锁时，那么它们将永远被阻塞。在线程A持有锁a并且想获得锁b时，线程B持有锁b并尝试获得a时，那么这两个线程将永远的等待下去。这种情况就是最简单的死锁形式：
public class TestDead {
private Object a;
private Object b;
public TestDead(Object a, Object b) {
this.a = a;
this.b = b;
}
public void funOne(){
synchronized (a){
System.out.println("finOne");
try {
Thread.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
funTwo();
}
}
public void funTwo(){
synchronized (b){
System.out.println("finTwo");
try {
Thread.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
funOne();
}
}
}
TestDead testDead = new TestDead(new Object(), new Object());
new Thread(new Runnable() {
@Override
public void run() {
testDead.funOne();
}
}).start();
new Thread(new Runnable() {
@Override
public void run() {
testDead.funTwo();
}
}).start();
程序的运行结果如下：
上面的代码会造成线程的假死，在没有外力作用下。两个线程会永远处于阻塞的状态，等待一把永远不可以释放的锁。
产生死锁的必要条件
- 互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。
- 占有且等待：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。
- 不可强行占有:指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
- 循环等待条件:指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。
<u>这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。</u>
死锁的避免与诊断
与许多其他并发危险一样，死锁造成的影响很少会立刻呈现出来。如果一个类可能发生死锁，并不意味这每次都会发生死锁，而是只表示有可能。当死锁发生时，往往是在最糟糕的时刻——在高负载情况下。
上文中的代码锁产生的死锁可以通过查看是否存在嵌套的锁获取操作来检查是否存在死锁的可能。但有时候获取多个锁的操作并不会这么明显。
要避免出现死锁的问题，只需要破坏四个条件中的任何一个就可以了：
- 打破互斥条件。即允许进程同时访问某些资源。当然，这种方法试用范围并不广，因为有的资源不允许并发访问，或者存在线程安全问题。
- 打破占有且等待条件。可以通过规定在任何情况下，一个线程获取一个锁之后，必须归还了锁之后才能请求另一锁
- 打破不可抢占条件。除非线程自己还钥匙，否则线程会一直占有钥匙，是形成不可抢占条件的原因。允许进程强行从占有者那里夺取某些资源。就是说，当一个进程已占有了某些资源，它又申请新的资源，但不能立即被满足时，它必须释放所占有的全部资源，以后再重新申请。
- 打破循环等待条件。采用这种策略，即把资源事先分类编号，按号分配，可以强制规定任何线程取锁的顺序。
其他活跃性危险
尽管死锁是最常见的活跃性危险，但在并发中还存在一些其他的活跃性危险，包括：饥饿、活锁等
饥饿：当线程由于无法访问它所需要的资源而不能继续执行时，就发生了饥饿。最常见的引发饥饿的资源就是CPU的时钟周期。
如果对线程的优先级使用不当，或者在持有锁时进行一些无法结束的操作（无限循环），就有可能产生饥饿，因为其他需要这个锁的线程永远无法得到它。
活锁：我为它赋予了一个充满神话色彩的名字西西弗斯锁，西西弗斯神话
这是另一种形式的活跃性问题，尽管它不会阻塞线程，但也不能继续向下执行，因为线程将不断重复执行相同的操作，而且总会失败。
当多个相互协作的线程都对彼此进行响应从而修改各自状态，并使任何一个线程都无法执行时，就会发生活锁。
活锁通常发生在处理事务的代码中：如果不能成功的处理某个消息，那么消息处理机制将回滚整个事务，并将它重新放置在队列的开头。因此，处理事务的代码将被反复调用，并返回相同的错误结果，虽然处理消息的线程没有被阻塞，但也无法执行下去。
小结
死锁（以及其他活跃性问题）是一个非常严重的问题，因为当它出现的时候，除了中止应用程序之外没有其他任何方法可以修复这种故障。在设计时应确保线程在获取多个锁时采用一致性的顺序。
