java - 多个 Java 线程看似锁定同一个监视器？

Question

在 Java 线程转储中，我发现了以下内容:

"TP-Processor184" daemon prio=10 tid=0x00007f2a7c056800 nid=0x47e7 waiting for monitor entry [0x00007f2a21278000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1725)
    - locked <0x0000000682f99d98> (a org.apache.jackrabbit.core.state.SharedItemStateManager)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:257)

"TP-Processor137" daemon prio=10 tid=0x00007f2a7c00f800 nid=0x4131 waiting for monitor entry [0x00007f2a1ace7000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1725)
    - locked <0x0000000682f99d98> (a org.apache.jackrabbit.core.state.SharedItemStateManager)
    at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:257)

这里的要点是两个线程都锁定了监视器<0x0000000682f99d98>(不管它们现在在等待两个不同的其他监视器)。

当查看线程转储分析器时，选择了该监视器，它确实在底部显示“线程锁定监视器:2”和“2 个线程锁定”。请看https://lh4.googleusercontent.com/-fCmlnohVqE0/T1D5lcPerZI/AAAAAAAAD2c/vAHcDiGOoMo/s971/locked_by_two_threads_3.png对于屏幕截图，我不允许在此处粘贴图片。

这是否意味着线程转储在监视器锁定信息方面不是原子的？我无法想象这真的是 JVM (1.6.0_26-b03) 的锁定错误。

Can several threads hold a lock on the same monitor in Java? 中已经提出了类似的问题，但对我的回答没有看到多个线程锁定同一个监视器的真正意义，即使它们可能正在等待其他监视器。

2014 年 5 月 13 日更新:

较新的问题 Multiple threads hold the same lock?有重现该行为的代码，@rsxg 已提交相应的错误报告 https://bugs.openjdk.java.net/browse/JDK-8036823按照他在这里的回答。

Answer 1

我不认为您的线程转储是说您的两个线程正在“等待两个不同的其他监视器”。我认为这是在说他们都在同一台监视器上等待，但在两个不同的代码点。这可能是堆栈位置或对象实例位置或其他东西。这是一份关于 analyzing the stack dumps 的很棒的文档.

Can several threads hold a lock on the same monitor in Java?

没有。您的堆栈转储显示两个线程锁定在同一监视器上的同一代码位置但在不同的堆栈帧中——或者任何看起来取决于操作系统的值。

编辑:

我不确定为什么线程转储似乎在说两个线程都锁定了一行，因为这似乎只有在它们处于 wait() 方法中时才允许。我注意到您正在链接到 1.6.5 版。那真的是您使用的版本吗？在版本 2.3.6(可能是最新的)中，1725 line实际上是一个wait。

1722        synchronized (this) {
1723            while (currentlyLoading.contains(id)) {
1724                try {
1725                    wait();
1726                } catch (InterruptedException e) {

---

即使它是独占 同步 锁，您也可以看到这种堆栈跟踪。例如，Linux 下的以下堆栈转储是针对来自同一代码行但在 Runnable.run() 方法的两个不同实例中锁定在同一对象上的两个线程。这是我的 stupid little test program .请注意，监视器条目编号不同，即使是相同的锁和相同的代码行号。

"Thread-1" prio=10 tid=0x00002aab34055c00 nid=0x4874
  waiting for monitor entry [0x0000000041017000..0x0000000041017d90]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00002aab072a1318> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <0x00002aab072a1318> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:619)

"Thread-0" prio=10 tid=0x00002aab34054c00 nid=0x4873
  waiting for monitor entry [0x0000000040f16000..0x0000000040f16d10]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00002aab072a1318> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <0x00002aab072a1318> (a java.lang.Object)
    at java.lang.Thread.run(Thread.java:619)

在我的 Mac 上，格式不同，但对于相同的行号，“监视器条目”后的数字也不相同。

"Thread-2" prio=5 tid=7f8b9c00d000 nid=0x109622000
  waiting for monitor entry [109621000]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <7f3192fb0> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <7f3192fb0> (a java.lang.Object)

"Thread-1" prio=5 tid=7f8b9f80d800 nid=0x10951f000
  waiting for monitor entry [10951e000]
java.lang.Thread.State: BLOCKED (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <7f3192fb0> (a java.lang.Object)
    at com.mprew.be.service.auto.freecause.Foo$OurRunnable.run(Foo.java:38)
    - locked <7f3192fb0> (a java.lang.Object)

This Oracle document将该值描述如下:

Address range, which gives an estimate of the valid stack region for the thread