What Causes Deadlock and How Do You Prevent It?

A deadlock is when two or more threads each hold a lock the other needs, so neither can proceed. The classic case is two threads locking two objects in opposite orders: thread A takes lock1 then wants lock2, thread B takes lock2 then wants lock1, and both wait forever.

The four conditions are the ones every interview asks for. Mutual exclusion — a lock can only be held by one thread at a time. Hold and wait — a thread holds one lock while waiting for another. No preemption — a lock cannot be forcibly taken away from the thread holding it. Circular wait — there is a cycle in the wait-for graph, so every thread is waiting for a thread that is waiting for it.

Java satisfies the first three automatically, which is why the interesting one is the fourth. You cannot make a monitor pre-emptible, and you cannot stop a thread holding a lock from waiting for another. So deadlock prevention in Java is almost entirely about breaking the circular wait — by establishing a global order for lock acquisition and always taking locks in that order, a cycle becomes impossible.

Two things make deadlocks more common than people expect. Nested locks acquired in different orders in different methods are the usual culprit, especially in code where the order was never written down. And wait on a condition object that is not the one you are being notified on is a deadlock that looks like a lost notification.

Here is the same thing as runnable code:

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Object lockA = new Object();
        Object lockB = new Object();

        Thread t1 = new Thread(() -> {
            synchronized (lockA) {
                sleepQuietly(50);
                synchronized (lockB) {
                    System.out.println("t1 got both locks");
                }
            }
        }, "t1");

        Thread t2 = new Thread(() -> {
            synchronized (lockB) {
                sleepQuietly(50);
                synchronized (lockA) {
                    System.out.println("t2 got both locks");
                }
            }
        }, "t2");

        t1.setDaemon(true);
        t2.setDaemon(true);
        t1.start();
        t2.start();

        t1.join(500);
        t2.join(500);
        System.out.println("t1 state: " + t1.getState());
        System.out.println("t2 state: " + t2.getState());
        System.out.println("both are BLOCKED waiting for each other");
    }

    static void sleepQuietly(long ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

Detection comes in two forms. ThreadMXBean has a findDeadlockedThreads method that returns the ids of the threads involved in a deadlock, and a findMonitorDeadlockedThreads variant that also finds deadlocks involving legacy monitors. And jstack on a running process prints the same information, along with the full stack of every thread, which is usually what you want in production.

Prevention is mostly about discipline. Establish a global lock order and document it, so that every piece of code acquires locks in the same sequence — that alone eliminates the circular wait. Reduce the scope of every critical section, and never hold a lock while doing IO or calling code you do not control. Avoid nested locks where you can. And in a producer-consumer design, use a BlockingQueue rather than hand-rolled wait and notify, because the queue already handles the handshake correctly.

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;

public class Main {
    public static void main(String[] args) throws InterruptedException {
        ReentrantLock lockA = new ReentrantLock();
        ReentrantLock lockB = new ReentrantLock();

        Thread t1 = new Thread(() -> {
            boolean gotA = false;
            boolean gotB = false;
            try {
                gotA = lockA.tryLock(500, TimeUnit.MILLISECONDS);
                if (!gotA) {
                    System.out.println("t1 could not get A");
                    return;
                }
                sleepQuietly(200);
                gotB = lockB.tryLock(50, TimeUnit.MILLISECONDS);
                System.out.println("t1 got B   : " + gotB);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                if (gotB) {
                    lockB.unlock();
                }
                if (gotA) {
                    lockA.unlock();
                }
            }
        }, "t1");

        Thread t2 = new Thread(() -> {
            boolean gotA = false;
            boolean gotB = false;
            try {
                gotB = lockB.tryLock(500, TimeUnit.MILLISECONDS);
                if (!gotB) {
                    System.out.println("t2 could not get B");
                    return;
                }
                sleepQuietly(50);
                gotA = lockA.tryLock(500, TimeUnit.MILLISECONDS);
                System.out.println("t2 got A   : " + gotA);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                if (gotA) {
                    lockA.unlock();
                }
                if (gotB) {
                    lockB.unlock();
                }
            }
        }, "t2");

        t1.setDaemon(true);
        t2.setDaemon(true);
        t1.start();
        t2.start();
        t1.join(2000);
        t2.join(2000);
        System.out.println("both threads finished without deadlocking");
    }

    static void sleepQuietly(long ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

The output shows the fix in action. t1 grabs A and then fails to get B within its 50ms budget, so it backs off and releases A. t2 is then able to take A and completes. Because tryLock never blocks indefinitely, the circular wait can never form.

What tryLock buys you is liveness at the cost of more complex code. The thread that cannot get the lock has to decide what to do instead — retry, give up, or take a different path — and that decision has to be written explicitly. The pattern to use is always try, then on failure back off for a short random interval and retry, so that two threads do not simply collide again in lockstep.

ThreadMXBean exposes deadlock detection directly. findDeadlockedThreads returns the ids of the threads that are deadlocked, and findMonitorDeadlockedThreads covers the older monitor-based deadlocks as well. If there is no deadlock, both return null.

Once you have the thread ids, you can call getThreadInfo with those ids to obtain the stack traces of the deadlocked threads, plus the lock names and the thread that owns each lock. That is often enough to point straight at the two methods that are fighting over the monitor.

Reading the result is straightforward. With no deadlock the detection method returns null; when there is one it returns the thread ids, and the matching thread info gives you the lock each thread is waiting on and the name of the thread that owns it — which is usually enough to identify the offending pair of methods. The dumpAllThreads method gives you the same information for every live thread without needing to know the ids in advance, which is what you want when you are surveying a running process rather than hunting a known deadlock.

The output shows the shape of the API. With no deadlock, the detection method returns null. When there is one, you get the thread ids, and then the thread info gives you the lock each thread is waiting on and the name of the thread that owns it — which is usually enough to identify the offending pair of methods.

Two practical notes. The deadlock detection methods need the JVM to have been started with the appropriate capability, which is on by default for the modern collectors, but can be unavailable in some environments. And jstack gives you the same information for a running process without needing to change any code, which is why it is usually the first thing you reach for in production.