1 pièce(s) jointe(s)
Aide pour comprendre un thread dump
Bonjour tous le monde !
Je rencontre un souci a mon travail qui concerne le blockage d'un thread. Ce phénomène se reproduit relativement souvent et je n'arrive toujours pas a comprendre le souci.
J'espere que vous pourrez m'eclairer en analysant le thread dump que j'ai genere. J'ai essaye d'analyzer via un thread analyser en ligne mais cela n'a pas fait avance.
Ma question est la suivante :
Je m'interesse au thread nomme : https-jsse-nio-18443-exec-28
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| "https-jsse-nio-18443-exec-28" #241 daemon prio=5 os_prio=0 tid=0x00007f68997f9000 nid=0x3d28 waiting on condition [0x00007f519320c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00007f572887f6f0> (a java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
at com.cyber.perpetual.persistence.GraphPersistence.snapshot(GraphPersistence.java:123)
- locked <0x00007f56c5accae0> (a com.cyber.perpetual.persistence.GraphPersistence)
at com.cyber.controllers.pong.PongController.snapshot(PongController.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151) |
Nous pouvons voir que ce thread a reussi a locker le ReadWriteLock (necessaire a la poursuite de son execution - le thread lock l'ecriture).
Code:
- locked <0x00007f56c5accae0> (a com.cyber.perpetual.persistence.GraphPersistence)
et pourtant mon thread a un status WAITING avec pour condition :
Code:
- parking to wait for <0x00007f572887f6f0> (a java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
Je ne retrouve aucun thread qui a locker cette reference de lock <0x00007f572887f6f0> dans tous mon thread dump. En revanche beaucoup de threads ont le meme status que mon thread https-jsse-nio-18443-exec-28
Est ce un lock suplementaire qui fait parti du mechanisme du ReadWriteLock ? Mais dans ce cas la quel thread le lock ?
J'aimerai comprendre quel est ce lock et comment identifier qui possede ce lock.
Merci de votre aide.
J'ai compresse le threaddump (zip) et joins a ce message.
Pièce jointe 605322
=========== UPDATE ===============
Apres avoir analyser une nouvelle fois le threaddump, je peux voir qu'un des threads qui utilise le read lock a un status RUNNABLE.
Peux-on comprendre que bien que le thread qui souhaite ecrire est reussi a locker le write lock, il attend que le thread qui lit est termine ? Le readlock a la propriete fair = true.
Si c'est le cas, ne devrait t'on pas voir que le thread qui souhaite ecrire soit BLOCKED sur le write lock au lieu de voir qu'il a reussi a locker :
Code:
- locked <0x00007f56c5accae0> (a com.cyber.perpetual.persistence.GraphPersistence)
