ConcurrentHashMap 是否有可能“死锁"? [英] Is it possible for ConcurrentHashMap to "deadlock"?

问题描述

我们在使用 ConcurrentHashMap 时遇到了一个奇怪的问题，其中两个线程似乎在调用 put()，然后在方法 Unsafe 中永远等待.公园().从外面看，ConcurrentHashMap内部就像一个死锁.

到目前为止，我们只见过这种情况发生一次.

谁能想到可能导致这些症状的任何事情?

编辑:相关线程的线程转储在这里:

<前> 线程 2" prio=10 tid=0x000000005bbbc800 nid=0x921 等待条件 [0x0000000040e93000]java.lang.Thread.State: WAITING(停车)在 sun.misc.Unsafe.park(本地方法)- 停车等待<0x00002aaaf1207b40>(一个 java.util.concurrent.locks.ReentrantLock$NonfairSync)在 java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)在 java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)在 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)在 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)在 java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)在 java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)在 java.util.concurrent.ConcurrentHashMap$Segment.put(ConcurrentHashMap.java:417)在 java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:883)在 线程 0" prio=10 tid=0x000000005bf38000 nid=0x91f 等待条件 [0x000000004151d000]java.lang.Thread.State: WAITING(停车)在 sun.misc.Unsafe.park(本地方法)- 停车等待<0x00002aaaf1207b40>(一个 java.util.concurrent.locks.ReentrantLock$NonfairSync)在 java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)在 java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)在 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)在 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)在 java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)在 java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)在 java.util.concurrent.ConcurrentHashMap$Segment.put(ConcurrentHashMap.java:417)在 java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:883)在

解决方案

也许不是您想要的答案，但这可能是 JVM 错误.见

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6865591

We have come across a strange issue with ConcurrentHashMap, where two threads appears to be calling put(), and then waiting forever inside the method Unsafe.park(). From the outside, it looks like a deadlock inside ConcurrentHashMap.

We have only seen this happen once so far.

Can anyone think of anything that could cause these symptoms?

EDIT: The thread dump for the relevant threads is here:

"[redacted] Thread 2" prio=10 tid=0x000000005bbbc800 nid=0x921 waiting on condition [0x0000000040e93000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00002aaaf1207b40> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
    at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
    at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
    at java.util.concurrent.ConcurrentHashMap$Segment.put(ConcurrentHashMap.java:417)
    at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:883)
    at [redacted]


"[redacted] Thread 0" prio=10 tid=0x000000005bf38000 nid=0x91f waiting on condition [0x000000004151d000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00002aaaf1207b40> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
    at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
    at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
    at java.util.concurrent.ConcurrentHashMap$Segment.put(ConcurrentHashMap.java:417)
    at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:883)
    at [redacted]

解决方案

Maybe not the answer you want, but this may be a JVM bug. See

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6865591

这篇关于ConcurrentHashMap 是否有可能“死锁"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！