如何在Java中识别监视器锁的所有者

使用WildFly 8.2.1和Java 1.8_92运行的Java应用程序完全挂起在巨大的负载上。这种情况下的线程转储显示许多线程处于等待监视器0x00000005cc562228的状态：

"default task-100" #825 prio=5 os_prio=0 tid=0x00000000033a2800 nid=0x49bd in Object.wait() [0x00007f238cb98000]
    java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1465)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:644)
    - locked <0x00000005cc562228> (a com.mchange.v2.resourcepool.BasicResourcePool)
    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:554)
    .......

“默认任务-100”-825优先级=5操作系统优先级=0 tid=0x00000000033a2800 nid=0x49bd在Object.wait（）中[0x00007f238cb98000]
java.lang.Thread.State:正在等待（在对象监视器上）
在java.lang.Object.wait（本机方法）
位于com.mchange.v2.resourcepool.BasicResourcePool.waitAvailable（BasicResourcePool.java:1465）
位于com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource（BasicResourcePool.java:644）
-锁定（com.mchange.v2.resourcepool.BasicResourcePool）
位于com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource（BasicResourcePool.java:554）
.......

我们如何才能找到这个监视器锁的所有者，因为我们假设这个线程是某些连接泄漏的原因？我们假设此监视器锁出现在另一个上下文中，但事实并非如此

---

或者，对于死锁的情况，是否有任何其他提示？非常感谢您的帮助，因为我们在这个问题上苦苦挣扎了很长时间。

实际上，这是线程（

默认任务-100

）拥有与

0x00000005cc562228

对应的锁，这要感谢线程调用堆栈中的

-locked

如果您使用像

JConsole

这样的工具，在

线程

选项卡中，您可以通过按钮“

检测死锁

”来检测死锁

---

但是，在您的情况下，它似乎不是死锁，因为锁的所有者显然在等待对象池中的对象的可用性。我猜它是一个连接池，因此您应该增加连接池的最大大小以避免此类问题。

它挂起的原因不是这些线程等待锁变为可用，而是等待调用notify（All）&某个线程可能拥有池中的资源（或忘记通知）。如果锁定被阻止，您会看到类似“等待监视器输入”（例如in）的内容。但是，在增加池大小之前，您应该检查（并测试）连接另一端（以及您的应用程序）的资源是否能够处理增加的连接数。或者修复根本原因，也可能是另一端的死锁（例如，如果是数据库，行死锁等）。增加连接池的大小只会延迟应用程序挂起的时间。仔细查看threaddump，会发现有30多个线程在同一个锁对象上等待，堆栈跟踪总是相同的，只是线程id不同。由于只有一个线程可以是锁监视器的所有者，我认为这是一个输入错误，应该是“等待锁定”而不是“锁定”（请参阅）。但非常奇怪的是，这个特殊的锁没有出现在threaddump中的另一个上下文中。@user6345319如果是这样，那么代码中可能存在连接泄漏