JAVA并发编程笔记（四）-死锁

安全性和活跃性通常是相互牵制的，我们使用锁来保证线程安全，但是滥用锁可能引起锁顺序死锁。我们使用线程池和信号量来约束资源的使用，却可能形成资源死锁。

一：死锁

死锁最简单的形式：当线程A占有锁L时，想要获得锁M，但是同时线程B持有M，并尝试获得L，这样线程将永远的等待下去。相比于JVM处理死锁，数据库的设计就针对了监测死锁，以及从死锁中恢复。一个事务可能需要取得许多锁，并可能一直持有这些锁，直到所有事务提交，如果数据库检测到一个事务集发生了死锁，它会选择一个牺牲者，使它退出事务，这个牺牲者释放的资源使其他事务能够继续进行，应用程序可以重新执行那个被强迫停止的事务。而JVM是不能这样的，一旦发生死锁，唯一的方式就是中止并重启。死锁有锁顺序死锁，动态的锁顺序死锁，协作对象间的死锁，资源死锁。

二：避免和诊断死锁

1：尝试定时的锁

使用每个显式Lock类中定时tryLock特性（下一篇文章会提到），来替代使用内部锁机制。在内部锁的机制中，只要没有获得锁，就会永远保持等待。而显式的锁可以定义超时时间，在规定的时间之后tryLock还没有获得锁会返回失败，通过这个异常咱们可以搞一点事情。

2：通过线程转储来诊断死锁

JVM使用线程转储（thread dump）来帮助你识别死锁，线程转储包括每个运行中线程的栈追踪信息，以及与之相似并随之发生的异常，线程转储也包括锁的信息，例如：那个锁有由那个线程获得，其中获得这些所得栈结构，以及阻塞线程正在等待的锁是哪一个，在生成线程转储之前，JVM在表示“正在等待的（is-waiting-for）”关系的有向图中循环搜索来发现死锁，如果发现死锁，他就会包括死锁的识别信息，其中参与了那些锁和线程，以及程序中造成不良后果的锁清秋发生在哪里。

三：其他类型的危险

死锁是我们遇到的最主要的活跃度危险，并发程序中仍然可能遇到一些其他的活跃度危险：饥饿，丢失信号和活锁。

1：饥饿

当线程访问它所需要的资源是被永久拒绝，以至于不能再继续进行，这样就发生了饥饿。最常见的引发饥饿的资源是CPU周期。在Java应用程序中，使用线程的优先级不当可能引起饥饿。在锁中执行无终止的构建也可能引起饥饿，因为其他需要这个锁的线程永远不可能得到他。

2：活锁

活锁是线程中活跃度失败的另一种形式，尽管没有被阻塞，线程仍然不能继续，因为它重试相同的操作，却总是失败。活锁通常发生在消息处理应用程序中，如果消息处理失败，传递消息的底层框架会回退整个事务。并把它置为队列首，这样被处理器重复调用，程序卡死在这里。活锁同样发生在多个相互协作的线程间，当它们为了彼此间响应而修改了状态，使得没有一个线程能够继续前行，那么就发生了活锁。