Java thread dump: Différence entre les “en attente de verrouillage” et “parking à attendre”?

Dans une Java thread dump, vous pouvez voir les verrous mentionné dans les traces de pile.

Il semble y avoir trois types de renseignements:

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 fil a obtenu un verrou sur l'objet 0x00002aab329f7fa0.
  • 2&3: l'air de dire que le thread est en attente d'un verrou sur l'objet de devenir disponible...

    mais quelle est la différence 2 et 3?
  • Je demande parce que je suis en train de corriger cette prometteuse open source verrouille l'outil de visualisation: gist.github.com/3039126
InformationsquelleAutor Nicolas Raoul | 2012-07-05
  1. 43

    Vous aurez "en attente de verrouillage" dans le thread dump lors de l'utilisation intrinsèque de serrures et de "parking à attendre" lors de l'utilisation de verrous à partir de java.util.de façon concomitante. 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();
    }

}

    Avec lockTest.intrinsicLock() vous obtenez les éléments suivants thread dump:

    "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$1.run(LockTest.java:11)
    at java.lang.Thread.run(Thread.java:662)

    tout lockTest.reentrantLock() produire:

    "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$2.run(LockTest.java:25)
    at java.lang.Thread.run(Thread.java:662)
    • Quelle est la "différence" entre les deux états?
    InformationsquelleAutor rgerganov
  2. 2

    À mon avis, la java.util.simultanées package utilise presque LockSupport.park() méthode pour bloquer le thread, comme CountDownLatch, ReentrantLock qui appartiennent à abstractqueuedsynchronized cadre.
    Ainsi, le 3ème scénario dans vos questions signifie que votre code appelle enfin LockSupport.park() la méthode, pour vous, l'utilisation simultanée de classe en java.util.simultanées paquet, le 2e scénario signifie que vous utilisez synchronisé clétage et l'appel en attente() la méthode explicite.

    InformationsquelleAutor binnchx chen