In the "Classes" view I filtered by the class name of the class that contains the lock as a field.I opened it using Java VisualVM, which comes with JDK.A heap dump was taken at roughly the same time as the thread dumps.For those interested in how, here's the process step-by-step:
The only way to understand that was to inspect a heap dump of the application. The thread holding the lock was not reported as holding any locks in the thread dump, which made it difficult to diagnose. What else could be causing this behaviour? Is this a deadlock? I see that there is some change in the threads' state, but it could only be internal to the lock implementation. Taking a thread dump 4 seconds later yealds the same result, but all threads now report parking to wait for, which is different than 0x00000002b8dd4ea8 in the first dump.I can't find another thread that could possibly be holding the same lock.This looks like a deadlock, however there are a couple of things that make me doubt that: Reader: "reader-1" #249 daemon prio=5 os_prio=0 tid=0x00007f895000c000 nid=0x33d6 waiting on condition Īt .AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)Īt .AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)Īt .ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727) parking to wait for (a .ReentrantReadWriteLock$FairSync)Īt .LockSupport.park(LockSupport.java:175)Īt .AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)Īt .AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)Īt .AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)Īt .ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943) This is on Java 8.īefore killing it someone took thread dumps, which look like this:
It froze for about an hour, producing no log output and not responding to requests. I have an application with 1 writer thread and 8 reader threads accessing a shared resource, which is behind a ReentrantReadWriteLock.
0 kommentar(er)
