JavaOne年度会议的一大优点是，主题专家介绍了几个技术和故障排除实验室。 其中的一个实验室今年特别吸引了我的注意力：“ HOL6500-查找和解决Java死锁 ”，由Java冠军Heinz Kabutz提出 。 这是我在该主题上看到的最好的演示之一。 我建议您自己下载，运行和研究实验室。
本文将重温这个经典的线程问题，并总结提出的关键故障排除和解决方法。 我还将根据自己的多线程故障排除经验来扩展主题。
Java死锁：这是什么？
真正的Java死锁本质上可以描述为两个或多个线程永远被阻塞，互相等待的情况。 这种情况与其他更常见的“日常”线程问题模式（例如锁争用和线程争用，等待阻塞IO调用的线程等）截然不同。这种锁排序死锁情况可以如下所示：
在上面的可视示例中，线程A和线程B尝试以不同顺序获取2个锁是致命的。 一旦线程达到死锁状态，它们将永远无法恢复，从而迫使您重新启动受影响的JVM进程。
Heinz还描述了另一种死锁： 资源死锁 。 到目前为止，这是我在Java EE企业系统故障排除经验中最常见的线程问题模式。 资源死锁本质上是一种场景，其中一个或多个线程正在等待获取永远无法使用的资源，例如JDBC池耗尽。
锁排序死锁
您现在应该知道我是JVM线程转储分析的忠实拥护者 ； 对于参与Java / Java EE开发或生产支持的个人而言至关重要的技能。 好消息是，大多数JVM线程转储格式（HotSpot，IBM VM…）都可以很容易地对Java级别的死锁进行开箱即用的识别，因为它们包含本机死锁检测机制，该机制实际上将向您显示所涉及的线程。真正的Java级死锁场景以及执行堆栈跟踪。 可以通过您选择的工具（例如JVisualVM，jstack或本机例如基于Unix的操作系统上的kill -3 <PID>）捕获JVM线程转储。 在运行实验1之后，在JVM Java级死锁检测部分下面找到：
现在，这是简单的部分……根本原因分析工作的核心是首先了解为什么此类线程涉及死锁情况。 锁顺序死锁可能会从您的应用程序代码中触发，但是除非您参与高并发性编程，否则，可能的罪魁祸首是您正在使用的第三方API或框架或实际的Java EE容器本身（如果适用）。
现在让我们在下面回顾一下亨氏提出的锁排序死锁解决策略：
＃通过全局排序解决死锁（请参阅lab1解决方案）
- 本质上涉及对锁的全局排序的定义，它将始终防止死锁（请参阅lab1解决方案）
＃TryLock解决死锁（请参阅lab2解决方案）
- 锁定第一把锁
- 然后尝试锁定第二把锁
- 如果您可以锁定它，那就很好了
- 如果不能，请再试一次
可以使用Java Lock＆ReantrantLock来实现上述策略，这也使您能够灵活地设置等待超时，以防止在第一个锁获取时间太长的情况下导致线程不足。
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException;
void unlock();
Condition newCondition();
}如果查看JBoss AS7实现，您会注意到Lock＆ReantrantLock在核心实现层中得到了广泛使用，例如：
- 部署服务
- EJB3实现（广泛使用）
- 集群和会话管理
- 内部缓存和数据结构（LRU，ConcurrentReferenceHashMap…）
现在，按照亨氏的观点，死锁解决方案＃2可能非常有效，但也需要采取适当的措施，例如通过finally {}块释放所有持有的锁，否则您可以将死锁方案转换为活动锁 。
资源僵局
现在，让我们转到资源死锁场景。 我很高兴Heinz的实验室＃3涵盖了这一点，因为根据我的经验，这是迄今为止您将看到的最常见的“死锁”场景，尤其是在开发和支持大型分布式Java EE生产系统时。
现在，让我们弄清事实。
- 资源死锁不是真正的Java级死锁
- 如果您遇到这些类型的死锁，那么JVM线程转储将不会神奇。 这意味着您需要做更多工作来分析和理解此问题作为起点。
- 当您刚开始学习如何读取线程转储时，线程转储分析可能会特别令人困惑，因为对于Java级死锁，线程通常会显示为RUNNING状态还是BLOCKED状态。 现在，重要的是要记住线程状态对于这种类型的问题不是那么重要，例如RUNNING state！= Healthy state。
- 分析方法与Java级别的死锁非常不同。 您必须创建多个线程转储快照，并确定每个快照之间的线程问题/等待模式。 您将能够看到线程没有移动，例如等待从池中获取资源的线程以及已经获取该资源并挂起的其他线程。
- 线程转储分析不是这里重要的唯一数据点/事实。 您将需要收集其他事实，例如有关线程正在等待的资源，整体中间件或环境运行状况等的统计信息。所有这些事实的结合将使您能够得出根本原因以及解决策略的结论，或可能不涉及代码更改。
我将以更多的线程转储问题模式与您联系，但首先请确保您对JVM线程转储的基本原理感到满意。
结论
我希望您像我一样有机会回顾，运行和享受亨氏演讲中的实验室。 并发编程和故障排除可能会非常具有挑战性，但是我仍然建议您花一些时间来理解其中一些原则，因为我相信您会在不久的将来遇到某种情况，这将迫使您进行这种深入研究并掌握这些原则。技能。
参考： Java EE支持模式和Java教程博客中的JCG合作伙伴 Pierre-Hugues Charbonneau提供的Java死锁故障排除和解决方法 。
https://www.javacodegeeks.com/2012/11/java-deadlock-troubleshooting-and-resolution.html
