Java thread dump: Différence entre les "en attente de verrouillage" et "parking à attendre"?
dans un fichier java thread, vous pouvez voir les serrures mentionnées dans les traces de la pile.
Il semble y avoir trois types d'informations:
1:
- locked <0x00002aab329f7fa0> (a java.io.BufferedInputStream)
2:
- waiting to lock <0x00002aaaf4ff6fa0> (a org.alfresco.repo.lock.LockServiceImpl)
3:
- parking to wait for <0x00002aaafbf70bb8> (a java.util.concurrent.SynchronousQueue$TransferStack)
- 1: le thread a obtenu un verrouillage sur l'objet 0x00002aab329f7fa0.
- 2 & 3: semble dire que le thread attend que le verrou sur ledit objet soit disponible...
mais quelle est la différence 2 et 3?
2 réponses
vous obtiendrez "waiting to lock "dans le thread dump lorsque vous utilisez des serrures intrinsèques et" parking to wait for " lorsque vous utilisez des serrures de java.util.simultané. Considérons l'exemple suivant:
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class LockTest {
final Lock lock = new ReentrantLock(true);
synchronized void intrinsicLock() {
Thread th = new Thread(new Runnable() {
public void run() {
intrinsicLock();
}
}, "My thread");
th.start();
try {
th.join();
} catch (InterruptedException e) {
}
}
void reentrantLock() {
lock.lock();
Thread th = new Thread(new Runnable() {
public void run() {
reentrantLock();
}
}, "My thread");
th.start();
try {
th.join();
} catch (InterruptedException e) {
}
lock.unlock();
}
public static void main(String[] args) {
LockTest lockTest = new LockTest();
lockTest.intrinsicLock();
//lockTest.reentrantLock();
}
}
lockTest.intrinsicLock() vous obtiendrez le dump de thread suivant:
"My thread" prio=10 tid=0x00007fffec015800 nid=0x1775 waiting for monitor entry [0x00007ffff15e5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at LockTest.intrinsicLock(LockTest.java:9)
- waiting to lock <0x00000007d6a33b10> (a LockTest)
at LockTest.run(LockTest.java:11)
at java.lang.Thread.run(Thread.java:662)
lockTest.reentrantLock() produit:
"My thread" prio=10 tid=0x00007fffec082800 nid=0x17e8 waiting on condition [0x00007ffff14eb000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007d6a33d30> (a java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)
at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:201)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
at LockTest.reentrantLock(LockTest.java:22)
at LockTest.run(LockTest.java:25)
at java.lang.Thread.run(Thread.java:662)
À mon avis, la java.util.le paquet concurrent utilise presque LockSupport.méthode park () pour bloquer le thread, tel que CountDownLatch, ReentrantLock qui appartient à abstractqueuedsynchronized framework. Ainsi, le 3ème scénario dans vos questions signifie que votre code appelle finalement LockSupport.méthode park (), pour vous utilisez la classe concurrent en java.util.paquet concurrent, le 2ème scénario signifie que vous utilisez explicitement la méthode synchronized keywork et call wait ().