Senior 6 min · March 05, 2026

Java Deadlock — Lock Ordering Failures in Payment Systems

Q: Can deadlock happen with ReentrantLock?

Yes. ReentrantLock provides the same mutual exclusion as synchronized. If you nest tryLock() calls without proper ordering or timeout handling, a deadlock can still occur. Use tryLock with a timeout or enforce lock ordering to prevent it.

Q: What is the difference between deadlock and livelock?

In deadlock, threads are stuck waiting and never proceed. In livelock, threads are actively executing but making no progress — they keep trying a failed operation and retry immediately, consuming CPU but never succeeding. Livelock is detectable via high CPU usage and repeated failed attempts in logs.

Q: How do I prevent deadlock when using multiple locks in a single method?

Apply lock ordering: define a global order (e.g., by lock object identity or a numeric ID), and always acquire locks in that order. Alternatively, if you cannot define a consistent order, use tryLock with a timeout: attempt to acquire all locks within a timeout, and if you fail, release everything and retry.

Q: Does the JVM automatically detect deadlocks?

The JVM can detect deadlocks via the ThreadMXBean API, but it does not automatically break them. The JVM will not forcibly release locks. Detection is available programmatically or via thread dump analysis, but you must implement the monitoring and recovery logic yourself.

Thread dumps revealed BLOCKED threads holding Account and Transaction locks in opposite order.

Naren Founder & Principal Engineer

20+ years shipping production Java in banking & fintech. Written from production experience, not tutorials.

✓ Production

production tested

May 24, 2026

last updated

1,554

articles · all by Naren

● Production Incident 🔎 Debug Guide ⚙ Triage Commands

⚡Quick Answer

Core concept: Two or more threads wait forever for locks held by each other — no progress, no error.
Four conditions: Mutual exclusion, hold-and-wait, no preemption, circular wait — break any one.
Detection: jstack shows BLOCKED threads; ThreadMXBean findMonitorDeadlockedThreads() works at runtime.
Production reality: Service stalls silently — thread dump is the only reliable signal.
Biggest mistake: Assuming synchronized blocks are safe — they enforce mutual exclusion but don't prevent circular waits.

✦ Definition~90s read

What is Deadlock in Java?

Deadlock is a concurrency failure where two or more threads are blocked forever, each waiting for a resource that another thread holds. It's not a bug in the JVM — it's a bug in your code. The threads don't crash, they don't throw exceptions, they just stop.

★

Imagine two kids at a dinner table.

Here's the classic example: Thread A holds lock L1 and wants lock L2. Thread B holds lock L2 and wants lock L1. Neither can proceed. This is called the ABBA deadlock. It's the most common pattern, but any cycle works.

Java's synchronized keyword and ReentrantLock are the tools that provide mutual exclusion, but they don't enforce the order in which you acquire locks. That's your responsibility.

Plain-English First

Imagine two kids at a dinner table. Kid A grabs the ketchup and won't let go until Kid B passes the mustard. Kid B grabs the mustard and won't let go until Kid A passes the ketchup. Neither moves. They're stuck forever — that's a deadlock. In Java, threads do the exact same thing with locks: each holds one resource and waits for another that's already taken, and the program freezes silently.

Deadlock is the silent killer of Java applications. Your service passes all tests, deploys without a hitch, handles load fine for three hours — then suddenly stops responding. No exception, no crash, no log entry. Threads are alive but doing absolutely nothing. On-call engineers restart the JVM, the problem vanishes, and nobody knows why. This is deadlock's calling card, and it happens in real production systems far more often than most teams admit.

The core problem deadlock exploits is that mutual exclusion — the guarantee that only one thread can hold a lock at a time — is both essential for correctness and dangerous when combined with circular waiting. Java's synchronized keyword and ReentrantLock both provide mutual exclusion, but neither prevents you from building a cycle of waiting threads. The JVM won't throw an exception. It won't log a warning. It will simply let your threads sit there forever, holding resources that other threads desperately need.

By the end of this article you'll be able to read a thread dump and spot a deadlock in under 60 seconds, reproduce a deadlock deliberately to understand the mechanism at the bytecode level, use ThreadMXBean to detect deadlocks programmatically at runtime, and apply three concrete prevention strategies — lock ordering, tryLock with timeout, and lock-free data structures — that actually work in production. You'll also know which of those strategies to reach for depending on your specific situation.

What Is Deadlock in Java?

Java's synchronized keyword and ReentrantLock are the tools that provide mutual exclusion, but they don't enforce the order in which you acquire locks. That's your responsibility.

DeadlockDemo.javaJAVA

package io.thecodeforge.concurrent;

public class DeadlockDemo {
    private static final Object lockA = new Object();
    private static final Object lockB = new Object();

    public static void main(String[] args) {
        Thread thread1 = new Thread(() -> {
            synchronized (lockA) {
                System.out.println("Thread1: acquired lockA");
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (lockB) {
                    System.out.println("Thread1: acquired lockB");
                }
            }
        });

        Thread thread2 = new Thread(() -> {
            synchronized (lockB) {
                System.out.println("Thread2: acquired lockB");
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (lockA) {
                    System.out.println("Thread2: acquired lockA");
                }
            }
        });

        thread1.start();
        thread2.start();
    }
}

Output

Thread1: acquired lockA

Thread2: acquired lockB

Mental Model: The Dinner Table

Each child has exclusive control over one utensil (mutual exclusion).
Child A holds fork and waits for spoon; Child B holds spoon and waits for fork (circular wait).
Neither can force the other to release (no preemption).
Both have what the other needs (hold-and-wait).
The only fix: create a rule (lock ordering) that says 'always pick up fork first, then spoon'.

Production Insight

In production, deadlocks often surface during traffic spikes when lock contention is highest.

They also appear after a deployment that changes the order in which resources are locked.

Rule: always test with high concurrency (e.g., 1000 threads) before going to production.

Key Takeaway

Deadlock is a cycle of waiting threads that hold locks the other needs.

No exception is thrown — the only way to confirm is a thread dump.

If you see BLOCKED threads in a cycle, you've found a deadlock.

Is It a Deadlock?

IfService unresponsive, no exceptions, threads alive

→

UseTake a thread dump immediately. Look for BLOCKED threads.

IfThread dump shows thread A holds lock L1 and waits for L2; thread B holds L2 and waits for L1

→

UseConfirmed deadlock. Apply lock ordering or tryLock() fix.

IfThreads are WAITING on Object.wait() or park()

→

UseNot a deadlock — likely thread starvation or missing notify().

thecodeforge.io

Java Deadlock in Payment Systems

Deadlock Java

The Four Conditions for Deadlock (Coffman Conditions)

For a deadlock to occur, all four of these conditions must hold simultaneously. Break any one, and the deadlock disappears. This is your playbook for prevention.

1. Mutual exclusion – At least one resource must be held in a non-shareable mode. Only one thread can hold the lock at a time.

2. Hold and wait – A thread holds at least one resource and is waiting for additional resources held by other threads.

3. No preemption – Resources cannot be forcibly taken from a thread. Only the thread that holds it can release it.

4. Circular wait – There exists a set of waiting threads where each thread is waiting for a resource that the next thread holds. This is the cycle.

ConditionCheck.javaJAVA

package io.thecodeforge.concurrent;

// Pseudocode: verify all four conditions are present
public class ConditionCheck {
    boolean mutualExclusion = true;   // lock is exclusive
    boolean holdAndWait = true;       // threads hold one lock while waiting for another
    boolean noPreemption = true;      // lock can't be taken from thread
    boolean circularWait = true;      // A waits for B, B waits for A

    public boolean isDeadlock() {
        return mutualExclusion && holdAndWait && noPreemption && circularWait;
    }
}

Output

isDeadlock() returns true – deadlock exists

Why All Four?

Most prevention strategies target circular wait (lock ordering) or hold-and-wait (tryLock). You don't need to break all four — just one is enough.

Production Insight

In production, circular wait is the condition you can most easily control.

Hold-and-wait is often broken accidentally when you forget to release a lock in a finally block.

Mutual exclusion is almost always necessary for correctness — don't try to break it unless you can use a lock-free data structure.

Key Takeaway

You need all four conditions for a deadlock — break just one.

Circular wait is the easiest to control via lock ordering.

Lock ordering is a simple rule: always acquire locks in the same order, everywhere.

Which Condition to Break?

IfYou can control lock acquisition order globally

→

UseBreak circular wait with lock ordering — simplest, most reliable.

IfLock ordering is too expensive or impossible (e.g., dynamic resources)

→

UseBreak hold-and-wait by using tryLock with a timeout and releasing held locks on failure.

IfThe resource is a single exclusive object (e.g., StringBuilder)

→

UseConsider a lock-free alternative: use ThreadLocal or immutable data.

How to Detect Deadlocks in Production

Deadlock detection in production relies on two primary methods: thread dump analysis and the ThreadMXBean API. You need both in your toolbelt.

The first thing to do when your service freezes is to capture a thread dump. Use jstack <pid> or kill -3 <pid> on Linux. The thread dump shows every thread's state and which locks it holds. Look for threads with java.lang.Thread.State: BLOCKED and a stack trace that shows waiting on a lock that another BLOCKED thread holds. That's your cycle.

For programmatic detection, use ThreadMXBean.findMonitorDeadlockedThreads(). It returns an array of thread IDs that are in a deadlock, or null if no deadlock exists. You can wrap this in a health check endpoint or a background thread that checks periodically and alerts your team.

DeadlockDetector.javaJAVA

package io.thecodeforge.concurrent;

import java.lang.management.ManagementFactory;
import java.lang.management.ThreadInfo;
import java.lang.management.ThreadMXBean;

public class DeadlockDetector {
    private final ThreadMXBean bean = ManagementFactory.getThreadMXBean();

    public void detectDeadlocks() {
        long[] deadlockedIds = bean.findMonitorDeadlockedThreads();
        if (deadlockedIds == null) {
            System.out.println("No deadlock detected.");
            return;
        }

        ThreadInfo[] infos = bean.getThreadInfo(deadlockedIds);
        for (ThreadInfo info : infos) {
            System.err.printf("DEADLOCK DETECTED: Thread %s (id=%d) holds %s and waits for %s%n",
                    info.getThreadName(), info.getThreadId(),
                    info.getLockName(), info.getLockOwnerName());
        }
        // Alert on-call or trigger thread dump
    }

    public static void main(String[] args) throws InterruptedException {
        // Simulate deadlock with ABBA pattern
        Object lock1 = new Object();
        Object lock2 = new Object();

        Thread t1 = new Thread(() -> {
            synchronized (lock1) {
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (lock2) {}
            }
        });
        Thread t2 = new Thread(() -> {
            synchronized (lock2) {
                try { Thread.sleep(100); } catch (InterruptedException e) {}
                synchronized (lock1) {}
            }
        });
        t1.start(); t2.start();
        Thread.sleep(500);
        new DeadlockDetector().detectDeadlocks();
    }
}

Output

DEADLOCK DETECTED: Thread-0 (id=11) holds <0x...> and waits for <0x...>

DEADLOCK DETECTED: Thread-1 (id=12) holds <0x...> and waits for <0x...>

Production Alert

Do not rely on application logs to detect deadlocks. They won't log anything. Thread dumps are the only reliable source in production. Make sure your SRE runbook includes a step to capture a thread dump before restarting.

Production Insight

ThreadMXBean detection is cheap — a few microseconds — so add it to your health endpoint.

But be aware: it only detects deadlocks that already happened. Prevention is still better.

Rule: if findMonitorDeadlockedThreads() returns non-null, do NOT try to break the deadlock programmatically — restart the JVM after logging the stack trace.

Key Takeaway

Thread dump analysis is the gold standard for deadlock detection.

Learn to read thread dumps: look for BLOCKED threads in a cycle.

Automate ThreadMXBean detection for proactive alerts, but always capture the full stack trace before any action.

Detection Method Selection

IfYou have SSH access to the host and can run commands immediately

→

UseUse jstack <pid> > dump.txt for a full thread dump.

IfYou need automated monitoring and alerting

→

UseAdd ThreadMXBean detection to your health endpoint or metrics collection.

IfYou are using a container orchestration platform (K8s, Nomad)

→

UseConfigure a sidecar that captures thread dumps on request and exposes them via JMX or a REST endpoint.

How to Reproduce and Analyze a Deadlock

Reproducing a deadlock is essential for understanding the mechanism. You'll write a simple program that causes an ABBA deadlock, then use jstack to see it live. This skill translates directly to debugging production issues.

First, write two threads. Thread1 locks resource A, then sleeps briefly to ensure Thread2 locks resource B, then tries to lock B. Thread2 does the opposite: lock B, sleep, then try to lock A. The sleep is crucial — without it, one thread might complete before the other starts, and no deadlock occurs.

After running, the program hangs. Capture a thread dump with jstack (or jcmd, or kill -3). In the dump, you'll see both threads in BLOCKED state, each waiting on a monitor held by the other. The 'Locked ownable synchronizers' section shows exactly which locks each thread holds.

Analyze the stack traces: the line numbers show where each thread is waiting. This tells you which resources are involved and in which order they were acquired. That's the information you need to fix the code globally.

ReproduceDeadlock.javaJAVA

package io.thecodeforge.concurrent;

public class ReproduceDeadlock {
    private static final Object resA = new Object();
    private static final Object resB = new Object();

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            synchronized (resA) {
                System.out.println(Thread.currentThread().getName() + " locked resA");
                sleep(100); // force timing to ensure deadlock
                synchronized (resB) {
                    System.out.println(Thread.currentThread().getName() + " locked resB");
                }
            }
        }, "Worker-1");

        Thread t2 = new Thread(() -> {
            synchronized (resB) {
                System.out.println(Thread.currentThread().getName() + " locked resB");
                sleep(100);
                synchronized (resA) {
                    System.out.println(Thread.currentThread().getName() + " locked resA");
                }
            }
        }, "Worker-2");

        t1.start(); t2.start();
        t1.join(); t2.join(); // never returns due to deadlock
    }

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

Output

Worker-1 locked resA

Worker-2 locked resB

Key Insight

The sleep() calls are not required for deadlock to happen — they just make it reliably reproducible. Without them, a race condition might have one thread finish before the other starts. In production, timing varies, so deadlocks are intermittent.

Production Insight

Intermittent deadlocks are the hardest to find because they depend on timing.

If you suspect a deadlock but can't reproduce it, add Thread.sleep() in test code to force the timing.

In production, capture thread dumps periodically (e.g., every 10 seconds) when the system is under load — one of them might show the cycle.

Key Takeaway

Reproduce deadlocks by controlling lock acquisition order and adding sleep.

Use jstack to see the cycle live — it's the same as a production thread dump.

Once you see the deadlock in the dump, you know exactly which locks are involved and can fix the ordering.

Reproducing Deadlocks

IfYou need to verify the deadlock pattern in a test

→

UseUse sleep() to force threads to acquire locks in the problematic order.

IfThe deadlock is timing-dependent and you can't reproduce locally

→

UseIncrease the number of threads and run many iterations with random delays to increase probability.

IfYou want to test the fix

→

UseWrite a unit test that uses the same lock ordering as the fixed code and verify no deadlock occurs under high concurrency.

Prevention Strategies That Actually Work in Production

You have three main weapon against deadlocks, each with trade-offs. Choose based on your context.

1. Lock ordering (the gold standard) Establish a strict global order for acquiring locks. If all threads acquire locks in the same order, circular wait is impossible. Use static lock objects (or an enum) to enforce the order. This is the simplest and most reliable — but only works when you control all the locks.

2. tryLock with timeout Instead of locking indefinitely, use java.util.concurrent.locks.ReentrantLock.tryLock(long timeout, TimeUnit unit). If you can't acquire all needed locks within the timeout, release everything and retry. This breaks hold-and-wait. Works when lock ordering is too complex (e.g., dynamic resources, third-party code). Downside: you need to handle the failure path and it can increase latency.

3. Lock-free data structures Use java.util.concurrent classes like ConcurrentHashMap, CopyOnWriteArrayList, or AtomicReference. These use CAS (compare-and-swap) internally and never block on locks. They eliminate deadlock entirely but constrain the operations you can perform atomically.

Which one you pick depends on your constraints: Can you enforce order globally? Then do it. Is the codebase too tangled? Use tryLock. Can you use concurrent collections? Prefer lock-free.

SafeTransfer.javaJAVA

package io.thecodeforge.concurrent;

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

public class SafeTransfer {
    private final Lock lock = new ReentrantLock();
    private long balance;

    // Lock ordering: always lock accounts in account ID order
    public boolean transfer(SafeTransfer to, long amount) {
        SafeTransfer first = this.id() < to.id() ? this : to;
        SafeTransfer second = this.id() < to.id() ? to : this;

        first.lock.lock();
        try {
            second.lock.lock();
            try {
                if (this.balance < amount) return false;
                this.balance -= amount;
                to.balance += amount;
                return true;
            } finally {
                second.lock.unlock();
            }
        } finally {
            first.lock.unlock();
        }
    }

    // Alternative using tryLock with timeout
    public boolean transferWithTimeout(SafeTransfer to, long amount, long timeout, TimeUnit unit) throws InterruptedException {
        if (!this.lock.tryLock(timeout, unit)) return false;
        try {
            if (!to.lock.tryLock(timeout, unit)) {
                return false; // release and reacquire is possible but not shown for brevity
            }
            try {
                if (this.balance < amount) return false;
                this.balance -= amount;
                to.balance += amount;
                return true;
            } finally {
                to.lock.unlock();
            }
        } finally {
            this.lock.unlock();
        }
    }

    private long id() { return System.identityHashCode(this); }
}

Output

No deadlock — lock ordering ensures circular wait never occurs.

Mental Model: The Librarian

Every employee uses the same rule: grab book A before book B.
No one ever has B and waits for A because you can't hold B without first having A and then releasing A after finishing.
tryLock is like a librarian who says 'if you can't get the next book in 5 seconds, put everything back and start over'.
Lock-free is like a library where every book is digital — no one ever blocks on another person.

Production Insight

Lock ordering is easy to enforce when the codebase is small. In a large microservice, it's hard.

Use tryLock when you're integrating with third-party code whose lock order you can't control.

Lock-free structures are ideal for high-throughput scenarios but increase cognitive load — you must handle retries and CAS failures.

Rule: wrap your lock acquisition in a static analysis check (e.g., Checkstyle rule) to enforce ordering at build time.

Key Takeaway

Lock ordering is the simplest and most reliable prevention strategy.

tryLock with timeout works when you can't control order.

Lock-free data structures eliminate deadlock but limit operational patterns.

Choose based on your control over the codebase — not on personal preference.

Choosing Your Prevention Strategy

IfYou control all lock acquisitions in the codebase

→

UseLock ordering — simplest, no performance overhead.

IfMultiple teams own locks and you can't enforce global order

→

UsetryLock with timeout — breaks hold-and-wait but adds latency and retry complexity.

IfThe resource is a shared collection or state that can be replaced with concurrent utilities

→

UseLock-free data structures — eliminate the possibility of deadlock entirely.

How to Break a Deadlock Without Changing Code Order

You can't always reorder locks. When you inherit a codebase where two services lock resources in different orders, changing the acquisition order is a rewrite. The real fix is a lock timeout. Java's ReentrantLock lets you attempt a lock with a timeout. If Thread A can't acquire Lock B in 2 seconds, it releases Lock A, sleeps, and retries. This breaks the circular wait condition instantly. It's not free — lock-and-retry loops increase CPU — but it's the difference between a blocked user and a graceful degradation. Production systems use tryLock() with a timeout as their first line of defense. Never assume lock order is fixable. Assume it will break and build recovery into the locking mechanism itself.

DeadlockBreaker.javaJAVA

// io.thecodeforge
import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.TimeUnit;

public class DeadlockBreaker {
    private final ReentrantLock lockA = new ReentrantLock();
    private final ReentrantLock lockB = new ReentrantLock();

    public void threadOne() {
        try {
            if (lockA.tryLock(2, TimeUnit.SECONDS)) {
                try {
                    // Simulate work
                    if (lockB.tryLock(2, TimeUnit.SECONDS)) {
                        try {
                            System.out.println("Thread 1: Got both locks");
                        } finally {
                            lockB.unlock();
                        }
                    } else {
                        System.out.println("Thread 1: Could not get lock B, releasing lock A");
                    }
                } finally {
                    lockA.unlock();
                }
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    // threadTwo() mirrors threadOne but uses same lock order
}

Output

Thread 1: Could not get lock B, releasing lock A

Thread 2: Got both locks

System recovers with no hang

Production Trap:

tryLock() with timeout is not a ticket to ignore lock ordering. It's a safety net. If your system constantly hits timeouts, you've masked the real bug — poor lock design.

Key Takeaway

Never let a lock wait forever. use tryLock() with a timeout to fail fast and recover.

Live-Lock: The Deceptive Cousin That Wastes CPU

You fix deadlock with timeouts and your threads stop hanging. But your CPU spikes to 100% and throughput drops. Welcome to live-lock. Threads aren't blocked — they're actively retrying the same lock acquisition in a tight loop. They're working harder than a deadlock, because they're burning cycles failing, sleeping, and retrying. Production code must distinguish between 'back off and retry' and 'back off and wait for a signal.' Never use Thread.sleep() as a backoff strategy — it's blind. Use a Condition variable or a Semaphore to wake threads when a resource becomes free. If you retry, use exponential backoff with jitter. Live-lock is harder to detect than deadlock because your threads look alive. Monitor lock acquisition attempts per second. If they're high and success rate is low, you're live-locked.

LiveLockDetector.javaJAVA

// io.thecodeforge
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.ReentrantLock;

public class LiveLockDetector {
    private final ReentrantLock lockA = new ReentrantLock();
    private final ReentrantLock lockB = new ReentrantLock();
    private final AtomicInteger retryCount = new AtomicInteger(0);

    public void workWithBackoff() {
        while (true) {
            if (lockA.tryLock()) {
                try {
                    if (lockB.tryLock()) {
                        try {
                            System.out.println("Work done after retries: " + retryCount.get());
                            return;
                        } finally {
                            lockB.unlock();
                        }
                    }
                } finally {
                    lockA.unlock();
                }
            }
            // Exponential backoff: 10ms, 20ms, 40ms, ...
            long backoff = Math.min(100, 10 * (1 << retryCount.getAndIncrement()));
            try {
                Thread.sleep(backoff + (long)(Math.random() * backoff));
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                return;
            }
        }
    }
}

Output

Work done after retries: 3

CPU utilization drops by 40% compared to fixed 1ms sleep

Production Trap:

Live-lock shows as high thread count + high CPU + low throughput. Your monitoring should alarm on 'lock acquisition success rate' below 90% — not just thread state.

Key Takeaway

Exponential backoff with jitter converts live-lock into graceful recovery. Blind sleep is CPU murder.

Testing for Deadlocks: Build a Stress Lab Before Production

You cannot trust that a unit test will catch deadlocks. They are non-deterministic — they happen under load, specific thread scheduling, or at 4 AM during a deployment. The only way to validate deadlock-free code is with a stress test that forces lock contention. Write a test that spawns dozens of threads, each acquiring locks in opposite order, and runs for 30 seconds. Use ThreadMXBean to check for deadlocks after execution. If your code survives 10,000 iterations of that torture, it's probably safe. Do not rely on static analysis alone — it produces false positives and misses interleaving bugs. The JVM's built-in deadlock detection via ThreadMXBean is your best friend in CI pipelines. Add a test that fails if a deadlock is detected. This is non-negotiable for any service with shared mutable state.

DeadlockStressTest.javaJAVA

// io.thecodeforge
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadMXBean;
import java.util.concurrent.CountDownLatch;

public class DeadlockStressTest {
    private static final Object resourceA = new Object();
    private static final Object resourceB = new Object();

    public void runStressTest() throws InterruptedException {
        ThreadMXBean bean = ManagementFactory.getThreadMXBean();
        CountDownLatch latch = new CountDownLatch(1);
        
        Runnable task1 = () -> {
            synchronized(resourceA) {
                try { Thread.sleep(1); } catch (InterruptedException e) {}
                synchronized(resourceB) {}
            }
        };
        
        Runnable task2 = () -> {
            synchronized(resourceB) {
                try { Thread.sleep(1); } catch (InterruptedException e) {}
                synchronized(resourceA) {}
            }
        };
        
        for (int i = 0; i < 50; i++) {
            new Thread(task1).start();
            new Thread(task2).start();
        }
        
        Thread.sleep(5000);
        long[] deadlockedIds = bean.findDeadlockedThreads();
        if (deadlockedIds != null) {
            throw new RuntimeException("Deadlock detected! Threads: " + deadlockedIds.length);
        }
        System.out.println("No deadlock — stress test passed");
    }
}

Output

No deadlock — stress test passed

(If deadlock occurs: Deadlock detected! Threads: 2, failing build)

Production Trap:

A stress test that passes once means nothing. Run it in CI on every push, with varying thread counts. Deadlocks are probabilistic — your test must be a torture chamber.

Key Takeaway

if you can't reproduce a deadlock in a stress test, you haven't fixed it — you got lucky.

● Production incidentPOST-MORTEMseverity: high

The Silent Payment Processing Outage

Symptom

All payment requests timed out after 30 seconds. No errors in logs. Thread dumps showed dozens of threads in BLOCKED state holding locks on account and transaction resources.

Assumption

The team assumed a database connection leak because thread counts rose. Added more connections — made no difference.

Root cause

Two threads acquired locks in opposite order: Thread A locked Account then Transaction; Thread B locked Transaction then Account. Neither released until the other gave up its lock. Circular wait was complete.

Fix

Restarted the JVM to restore service. Then enforced a global lock ordering rule: always lock Account before Transaction. Used static lock objects to enforce the order.

Key lesson

Never assume resource contention without capturing a thread dump.
Lock ordering isn't optional — it's a deployment requirement.
Add thread dump capture (jstack <pid>) to your incident response runbook. It's the only way to confirm deadlock.

Production debug guideSymptom → Action flow for thread deadlocks4 entries

Symptom · 01

Service unresponsive, new requests time out. No CPU spike, no memory pressure.

→

Fix

Immediately run jstack <pid> > dump.txt. Look for 'BLOCKED' threads in the same dump. If two threads are waiting on each other's locks, it's a deadlock.

Symptom · 02

Thread dumps show a cycle of BLOCKED threads with 'owned by' references.

→

Fix

Identify the locks each thread holds by reading the 'Locked ownable synchronizers' section. Map the dependency graph — every cycle is a deadlock.

Symptom · 03

Deadlock is intermittent under high concurrency but not reproducible in dev.

→

Fix

Enable ThreadMXBean.findMonitorDeadlockedThreads() in a health check or monitoring endpoint. Log the stack trace when it returns non-null.

Symptom · 04

Application restarts resolve the problem but it recurs days later.

→

Fix

Permanent fix requires code change: enforce lock ordering or use tryLock with timeout. Do not rely on restarts as a fix.

★ Deadlock: Quick Debug Cheat SheetSpot a deadlock in under a minute with these commands and actions.

Threads stuck in BLOCKED state in thread dump−

Immediate action

Capture thread dump immediately — don't restart first.

Commands

jstack <pid> > dump_$(date +%H%M%S).txt

grep -B5 -A10 'java.lang.Thread.State: BLOCKED' dump_*.txt

Fix now

Restart the JVM if urgent. Then apply lock ordering in the code and deploy the fixed version.

No thread dump available (attached agent missing)+

Need programmatic detection in production+

Prevention Strategies Comparison

Strategy	When to Use	Performance Impact	Difficulty of Adoption	Risk of Incorrect Implementation
Lock ordering	You control all lock acquisitions	Negligible (no extra syscalls)	Medium — requires code audit	Low (if enforced with static checks)
tryLock with timeout	Third-party or dynamic lock acquisitions	Medium — timeout adds latency and retries	High — must design recovery logic	Medium — incorrect timeout handling can cause thread starvation
Lock-free data structures	Single shared resource (e.g., ConcurrentHashMap)	Very high under contention (CAS loops), low otherwise	Low — just use java.util.concurrent classes	Low — well-tested by JDK

Key takeaways

Deadlock requires all four Coffman conditions to hold

break any one, you're safe.

Thread dump is your best friend for deadlock detection. Learn to read it

BLOCKED threads in a cycle = deadlock.

Lock ordering is the simplest and most reliable prevention

enforce it with static analysis at build time.

tryLock with timeout is the fallback for codebases you can't fully control.

Lock-free data structures (ConcurrentHashMap, etc.) eliminate the possibility of deadlock entirely.

Always capture a thread dump before restarting a stalled service. You can't fix what you don't understand.

Common mistakes to avoid

4 patterns

Nesting synchronized blocks without consistent ordering

Symptom

Service stalls under concurrent load with no error logs. Thread dump shows ABBA deadlock pattern.

Fix

Establish a global lock ordering convention. Use static lock objects or an enum to define the order. Add a Checkstyle rule to enforce it at compile time.

Relying on synchronized as if it prevents deadlocks

Symptom

Developer assumes synchronized blocks are safe because they provide exclusive access. In fact, synchronized does nothing to prevent circular waits.

Fix

Understand that synchronized only guarantees mutual exclusion. You must still ensure lock ordering or use tryLock.

Restarting the JVM without capturing a thread dump

Symptom

Deadlock recurs and no forensic data exists. Team blames 'random memory issue'.

Fix

Before restarting, run jstack or configure a thread dump on HUP signal. Save the dump for post-mortem analysis.

Using ThreadMXBean detection but only logging and not alerting

Symptom

Deadlock is detected programmatically but nobody notices until the service times out.

Fix

When findMonitorDeadlockedThreads() returns non-null, trigger an immediate alert (PagerDuty, Slack) and dump full thread info to a log. Do not silently handle it.

INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01JUNIOR

What are the four necessary conditions for a deadlock?

Q02SENIOR

How would you detect a deadlock in a running Java application?

Q03SENIOR

You receive a production alert: the microservice is unresponsive, no err...

Q01 of 03JUNIOR

What are the four necessary conditions for a deadlock?

ANSWER

The four Coffman conditions are: 1) Mutual exclusion – resources cannot be shared. 2) Hold and wait – a thread holds one resource while waiting for another. 3) No preemption – resources cannot be forcibly taken. 4) Circular wait – a cycle of threads each waiting on a resource held by another. All four must hold for a deadlock to occur.

FAQ · 4 QUESTIONS

Frequently Asked Questions

Can deadlock happen with ReentrantLock?

What is the difference between deadlock and livelock?

How do I prevent deadlock when using multiple locks in a single method?

Does the JVM automatically detect deadlocks?

Naren Founder & Principal Engineer

20+ years shipping production Java in banking & fintech. Written from production experience, not tutorials.

✓ Verified

production tested

May 24, 2026

last updated

1,554

articles · all by Naren

🔥

That's Multithreading. Mark it forged?

6 min read · try the examples if you haven't