多个Java线程似乎锁定同一个监视器？ [英] Multiple Java threads seemingly locking same monitor?

问题描述

在Java threaddump中，我发现了以下内容：

 TP-Processor184daemon prio = 10 tid = 0x00007f2a7c056800 nid = 0x47e7等待监视器输入[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- Processor137daemon prio = 10 tid = 0x00007f2a7c00f800 nid = 0x4131等待监视器输入[0x00007f2a1ace7000] 
 java.lang.Thread.State：BLOCKED（在对象监视器上）
在org.apache.jackrabbit.core。 state.SharedItemStateManager.getNonVirtualItemState（SharedItemStateManager.java:1725）
  -  locked< 0x0000000682f99d98> （a org.apache.jackrabbit.core.state.SharedItemStateManager）
在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 的屏幕截图，我不允许在此粘贴图像。
 
 
 
这是否意味着threaddumps aren相对于监视器锁信息？我不能想象这真的是JVM（1.6.0_26-b03）的一个锁定bug。
 
 
 
一个类似的问题已经在几个线程可以在Java中的同一个监视器上保持锁定？，但是我的答案没有看到多线程锁定同一个监视器的真正意义，即使他们可能正在等待一些其他。
 
 
 
 更新日期：2014年5月13日： 
 
 
 http://stackoverflow.com/questions/16249835/multiple-threads-hold-the-same-lock\">多线程持有相同的锁？有重现行为的代码，@rsxg提交了一个根据错误报告 https://bugs.openjdk.java.net/browse/JDK-8036823 沿着他的回答的线。
解决方案
你可能正在堆栈跟踪例程JVM在分析严重争用的锁时 - 它可能与此错误。
 
 
 
事实上，你的两个线程都没有实际上成功地获取 SharedItemStateManager  ，正如你可以看到，他们正在报告等待监视器输入。错误是，在两种情况下，在堆栈跟踪中进一步向上报告等待锁定而不是锁定。 / p> 
 
 
解析这样的奇怪堆栈跟踪时的解决方法是始终检查声明拥有锁定的线程
 
 
 
（不幸的是，此分析需要交叉引用堆栈跟踪中的行号与源代码，因为有在堆栈跟踪中的等待监视条目头和锁定行之间没有关系。 a href =http://docs.oracle.com/javase/8/docs/technotes/guides/tsgvm/tooldescr.html =nofollow>此Oracle文档，数字 0x00007f2a21278000   TP-Processor184daemon prio = 10 tid = 0x00007f2a7c056800 nid = 0x47e7等待监视器输入[0x00007f2a21278000]  em>线程的有效堆栈区域的估计值。所以它看起来像一个监视器ID，但它不是 - 你可以看到，你给的两个线程在不同的地址在堆栈）。
 
In a Java threaddump I found the following:
"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)
The point here being that both threads have locked monitor <0x0000000682f99d98> (regardless of them now waiting for two different other monitors). 

When looking at Thread Dump Analyzer, with that monitor being selected, it really says "Threads locking monitor: 2" at the bottom, and "2 Thread(s) locking". Please see https://lh4.googleusercontent.com/-fCmlnohVqE0/T1D5lcPerZI/AAAAAAAAD2c/vAHcDiGOoMo/s971/locked_by_two_threads_3.png for the screenshot, I'm not allowed to paste images here.

Does this mean threaddumps aren't atomic with respect to monitor lock information? I can't imagine this really being a locking bug of the JVM (1.6.0_26-b03).

A similar question has already been asked in Can several threads hold a lock on the same monitor in Java?, but the answer to me didn't see the real point of multiple threads locking the same monitor, even though they may be waiting for some other.

Update May 13th 2014:

Newer question Multiple threads hold the same lock? has code to reproduce the behaviour, and @rsxg has filed an according bug report https://bugs.openjdk.java.net/browse/JDK-8036823 along the lines of his answer here.
解决方案
You are probably running into a cosmetic bug in the stack trace routines in the JVM when analyzing heavily contended locks - it may or may not be the same as this bug.

The fact is that neither of your two threads have actually managed to acquire the lock on the SharedItemStateManager, as you can see from the fact that they are reporting waiting for monitor entry. The bug is that further up in the stack trace in both cases they should report waiting to lock instead of locked.

The workaround when analyzing strange stack traces like this is to always check that a thread claiming to have locked an object is not also waiting to acquire a lock on the same object.

(Unfortunately this analysis requires cross-referencing the line numbers in the stack trace with the source, code since there is no relationship between the figures in the waiting for monitor entry header and the locked line in the stack trace. As per this Oracle document, the number 0x00007f2a21278000 in the line TP-Processor184" daemon prio=10 tid=0x00007f2a7c056800 nid=0x47e7 waiting for monitor entry [0x00007f2a21278000]  refers to an estimate of the valid stack region for the thread. So it looks like a monitor ID but it isn't - and you can see that the two threads you gave are at different addresses in the stack).

                        
这篇关于多个Java线程似乎锁定同一个监视器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！