Analysis against JVM Thread Dump - Dead Lock

Dead Lock is a special error need to be avoided in multi-thread programming. It seldom introduces CPU high usage issue, however the most common phenomenon is that the system hangs and has no response to end user. Absolutely it is quite easy to be identified from JVM Thread Dump. In Oracle Agile PLM, I seldom see such issue except one case several years ago that I cannot remind.

I will not explain the principle of Dead Lock, which you can google everywhere. I will only describe how to analyze in JVM thread dump from below sample source code and thread dump.

Demonstration

Thread 0 tries to lock object x before it processes y, while Thread 1 tries to lock object y before it does to x. Each holds the resource which is expected by peer.

public class DeadLock implements Runnable {
    public int i = 1;
    static Object x = new Object(), y = new Object();

    public void run() {
        System.out.println("current thread=" + i);
        if (i == 0) {
            synchronized (x) { 
                try {
                    Thread.sleep(500);
                } catch (Exception e) {
                }
                synchronized (y) {
                    System.out.println("locked y");
                }
            }
        }
        if (i == 1) {
            synchronized (y) { 
                try {
                    Thread.sleep(500);
                } catch (Exception e) {
                }
                synchronized (x) {
                    System.out.println("locked x");
                }
            }
        }
    }

    public static void main(String[] args) {
        DeadLock test0 = new DeadLock();
        DeadLock test1 = new DeadLock();
        test0.i = 0;
        test1.i = 1;
        Thread t1 = new Thread(test0);
        Thread t2 = new Thread(test1);
        t1.start();
        t2.start();
    }
}

The program never ends to print the expected line ("locked x" and "locked y") like below,

Analysis

How the JVM thread dump reflect this behavior. Read the stack we see Thread-1 is waiting to lock 0x00000007d663a588 which represent object y, but 0x00000007d663a588 is already locked by Thread-0 (locked 0x00000007d663a588) . Same thing happens to 0x00000007d663a598 that represents object x.

There are a most important keywords "waiting for monitor entry" hint. Pay attention to keyword "BLOCKED". BLOCKED is the thread state result, not root cause, not reason. In many cases "BLOCKED" does not reflect any harmful thread. I may introduce more scenario in future if possible.

If we read through the whole thread dump we will see JVM smartly detects the Dead Lock by itself as below, which explain the same I stated above.

Note

• Dead Lock usually does not introduce CPU high usage issue
• Dead Lock usually makes system unresponsive
• Never rely on "BLOCKED" if to analyze JVM Thread Dump