我在我们的 Java 应用程序中遇到了另一个死锁，并开始考虑如何在未来检测潜在的死锁。我有一个如何做到这一点的想法，但它似乎太简单了。
我想听听人们对此的看法。
我计划使用典型的数据集在我们的测试环境中运行我们的应用程序几个小时。
我认为可以在我们的应用程序上执行字节码操作，这样，每当它需要一个锁（例如进入一个同步块）时，锁的细节就会被添加到一个 ThreadLocal 列表中。
我可以编写一个算法，在稍后的某个时间点，比较所有线程的列表并检查是否有任何线程以相反的顺序包含相同的锁对——这将被报告为死锁的可能性。同样，我将使用字节码操作将这种定期检查添加到我的应用程序中。
所以我的问题是：这个想法（a）是原创的，（b）是可行的吗？
这是我们在学习并发课程时谈到的。我不确定您的实现是否是原创的，但确定潜在死锁的分析概念并不是唯一的。有 Java 的动态分析工具，例如JCarder。还有一些可以静态进行的分析的研究。
诚然，我环顾四周已经有几年了。我不认为 JCarder 是我们讨论的特定工具（至少，这个名字听起来并不熟悉，但我找不到其他任何东西）。但关键是检测死锁的分析不是一个原始概念，我会从研究产生可用工具的研究开始——我怀疑算法，如果不是实现，通常是可用的.
Lock通过提供我自己的实现，我已经做了类似的事情。
这些天我使用actor模型，因此几乎不需要锁定数据（因为我几乎没有共享可变数据）
如果您不知道，您可以使用Java MX bean以编程方式检测死锁线程。这对您的测试没有帮助，但它至少可以帮助您在生产中更好地检测和恢复。
ThreadMXBean threadMxBean = ManagementFactory.getThreadMXBean();
long[] deadLockedThreadIds = threadMxBean.findMonitorDeadlockedThreads();
// log the condition or even interrupt threads if necessary
...
这样你可以找到一些死锁，但永远不能证明它们不存在。我最好开发静态检查工具，一种字节码分析器，为每个同步方法提供注释。注解应该显示被注解的方法在资源图中的位置。然后的任务是在图中找到循环。每个循环都意味着死锁。