Qu'est-ce que « Lock libéré en attendant: » moyenne dans une décharge de fil Java?

Question

Dans ce thread dump:

INFO   | jvm 3    | 2011/06/08 13:36:12 | "ExecuteThread: '38' for queue: 'default'" id=55 idx=0x78 tid=5316 prio=5 alive, in native, waiting, daemon
INFO   | jvm 3    | 2011/06/08 13:36:12 |     -- Waiting for notification on: weblogic/ejb20/locks/ExclusiveLockManager$LockWaiter@0x25EF8828[fat lock]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at jrockit/vm/Threads.waitForSignal(J)Z(Native Method)
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at java/lang/Object.wait(J)V(Native Method)[optimized]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at weblogic/ejb20/locks/ExclusiveLockManager$LockBucket.lock(Ljava/lang/Object;Ljava/lang/Object;I)Z(ExclusiveLockManager.java:504)[optimized]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     ^-- Lock released while waiting: weblogic/ejb20/locks/ExclusiveLockManager$LockWaiter@0x25EF8828[fat lock]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at weblogic/ejb20/locks/ExclusiveLockManager.lock(Ljava/lang/Object;Ljava/lang/Object;I)Z(ExclusiveLockManager.java:261)[optimized]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at weblogic/ejb20/manager/ExclusiveEntityManager.acquireLock(Ljava/lang/Object;Ljavax/transaction/Transaction;I)Z(ExclusiveEntityManager.java:210)[inlined]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at weblogic/ejb20/manager/ExclusiveEntityManager.getReadyBean(Ljava/lang/Object;Ljavax/transaction/Transaction;I)Ljavax/ejb/EntityBean;(ExclusiveEntityManager.java:267)[inlined]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at weblogic/ejb20/manager/ExclusiveEntityManager.preInvoke(Lweblogic/ejb20/internal/InvocationWrapper;)Ljavax/ejb/EnterpriseBean;(ExclusiveEntityManager.java:242)[optimized]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at weblogic/ejb20/internal/BaseEJBObject.preInvoke(Lweblogic/ejb20/internal/InvocationWrapper;Lweblogic/security/service/ContextHandler;)Lweblogic/ejb20/internal/InvocationWrapper;(BaseEJBObject.java:152)[inlined]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at weblogic/ejb20/internal/EntityEJBObject.preInvoke(Lweblogic/ejb20/internal/MethodDescriptor;Lweblogic/security/service/ContextHandler;)Lweblogic/ejb20/internal/InvocationWrapper;(EntityEJBObject.java:104)[inlined]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at foob/ejb/commodity/ejb_Commodity_etfd4i_EOImpl.getData()Lfoob/ejb/commodity/db/CommodityData;(ejb_Commodity_etfd4i_EOImpl.java:701)[optimized]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at foob/ejb/item/OurItem.loadCommodityData()V(OurItem.java:172)[optimized]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     ^-- Holding lock: java/lang/Class@0x067EA070[fat lock]
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at foob/ejb/item/OurItem.getCommodityData()Lfoob/ejb/commodity/db/CommodityData;(OurItem.java:251)
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at foob/ejb/item/OurItem.getTheControlGid()Ljava/lang/String;(OurItem.java:259)
INFO   | jvm 3    | 2011/06/08 13:36:12 |     at foob/business/shipment/OurThing.getTheControlGid(Lfoob/util/jdbc/OurConnection;)Ljava/lang/String;(OurThing.java:379)

Qu'est-ce que la ligne

Lock released while waiting: weblogic/ejb20/locks/ExclusiveLockManager$LockWaiter@0x25EF8828

signifie? Nous avions 8 autres threads bloqué en attente d'java/lang/Class@0x067EA070 être libéré, ce qui ce fil tient, mais je ne comprends pas ce que ce fil bloquait sur, ni ce que cela signifie que le verrou a été libéré. J'aurais pensé qu'une décharge de fil est un type d'événement stop du monde, et à cet effet la ligne en question ne serait pas référence à la serrure étant relâchée alors que la décharge de fil se passait ...

En outre, le fait où il semble avoir une signification (à savoir la ligne au-dessus et au-dessous)?

Il est évident que je ne suis pas Java attendre, donc j'espère que ce ne soit pas trop stupide d'une question. Merci pour l'aide!

Answer 1

Des Oracle JRockit JDK Guide Outils ,

La sémantique pour attendre (pour notification) pour un objet en Java est complexe un peu. Tout d'abord, d'entrer dans une bloc synchronisé, vous devez prendre la Serrure pour l'objet, puis vous appelez wait () sur cet objet. Dans l'attente méthode, le verrou est libéré avant le fil va dormir en attente d'une notification. Lorsque le fil reçoit une notification, attente () re-prend la verrouiller avant de revenir. Si un thread a pris une serrure, et attend notification de cette serrure, la ligne dans la trace de pile qui décrit quand la serrure a été prise non présentée comme (Verrouillage Holding); il est affiché comme (verrouillage publié en attendant.)

En d'autres termes, cela signifie que ledit fil a un objet qui a acquis un verrou plus tôt, puis ultérieurement libéré, quand elle a invoqué object.wait(). Le motif de code sur le comportement est:

synchronized(lock) //acquires the lock
{
   ...
   do some work
   ...
   object.wait(); //releases the lock, and waits for a notification
}

Mise à jour

En regardant la trace de la pile, il semble que vous utilisez Beans EJB entité, et compte tenu de la manière dont ces implémentations fonctionnent, les verrous sont généralement acquis sur les EJB entité. Cela en fait dépendre de la stratégie de concurrence utilisé pour gérer les transactions concurrentes qui doivent accéder à la base de données. Je pense que le nombre de grains est trop faible, ou il n'y a qu'un seul grain à verrou.

Answer 2

Chercher « Lock libéré » sur cette page et qui fournit une explication assez bien de ce qui se passe dans la logique d'attente sur l'objet.

http://download.oracle.com/ docs / cd / E13188_01 / JRockit / docs142 / UserGuide / apstkdmp.html

Il semble que ce message représente lorsque le verrou ed reprend la de l'objet appel qui obtient notify () attente d'origine ().

Pour référence ultérieure, je trouve cela en faisant simplement une recherche Google sur « Lock libéré en attendant » et ce fut la première page qui a montré ... nous espérons que vous l'avez déjà fait une recherche sur le net et juste été pas satisfait avec ce que vous avez trouvé, dans ce cas, je suis désolé si cela ne l'aide.

Answer 3

Il concerne plus probablement l'entrée deux lignes ci-dessus:

at java/lang/Object.wait(J)V(Native Method)[optimized]

wait () libère le verrou actuellement occupé (le verrou détenu par le périphérique bloc synchronisé) et attendre un signal notify ().