Для ConcurrentHashMap действительно ли возможно “зайти в тупик”?

Мы столкнулись со странной проблемой с ConcurrentHashMap, где два потока, кажется, звонят put(), и затем ожидая навсегда в методе Unsafe.park(). С внешней стороны это похоже на мертвую блокировку внутри ConcurrentHashMap.

Мы только видели, что это происходит однажды до сих пор.

Кто-либо может думать о чем-нибудь, что могло вызвать эти признаки?

Править: Дамп потока для соответствующих потоков здесь:


"[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]
23
задан Simon Nickerson 22 July 2010 в 16:36
поделиться

2 ответа

Возможно, это не тот ответ, который вам нужен, но это может быть ошибка JVM. См.

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

4
ответ дан 29 November 2019 в 03:04
поделиться

Package Unsafe является родным, реализация зависит от платформы.

Внезапное завершение третьего потока (на уровне платформы, исключение не является проблемой), который получил блокировку на карте, может вызвать такую ​​ситуацию - состояние блокировки нарушено, два других потока отключены и ждут, пока кто-то вызовет Unsafe.unpark () (И этого никогда не будет).

4
ответ дан 29 November 2019 в 03:04
поделиться
Другие вопросы по тегам:

Похожие вопросы: