Java Multithreading Deadlock — Payment Batch Hang

Multithreading questions separate senior Java developers from juniors faster than almost anything else in an interview. It's not enough to know that synchronized exists — interviewers at companies like Amazon, Google, and Goldman Sachs want to know what happens inside the JVM when two threads collide on a shared object, why volatile doesn't make compound operations atomic, and how the Java Memory Model actually defines 'visibility'. These are the questions that decide offers.

The real problem multithreading solves is utilising multi-core hardware. Modern servers have 32, 64, even 128 cores sitting idle if your application is single-threaded. But concurrency introduces an entirely new class of bugs — race conditions, deadlocks, liveness failures, and memory visibility errors — that are notoriously hard to reproduce and even harder to debug in production. A solid mental model is your only real defence.

By the end of this article you'll be able to answer the top Java multithreading interview questions with the depth and precision that impresses senior engineers. You'll understand the Java Memory Model, the monitor mechanism behind synchronized, the happens-before guarantee, the difference between Callable and Runnable at the implementation level, and the patterns that prevent deadlock. You'll walk into that interview room ready to discuss internals, not just syntax.

What Java Multithreading Deadlock Actually Is

A deadlock is a concurrency failure where two or more threads are blocked forever, each waiting on a resource held by another. The core mechanic is a circular dependency: thread A holds lock L1 and waits for L2, while thread B holds L2 and waits for L1. Neither can proceed. This is not a race condition — it's a deterministic stall. In Java, deadlock typically involves synchronized blocks, ReentrantLocks, or database transaction locks. The JVM can detect deadlocks via ThreadMXBean, but it cannot resolve them. Deadlock requires four conditions: mutual exclusion, hold-and-wait, no preemption, and circular wait. Remove any one, and deadlock is impossible. In practice, you control the last two: enforce a global lock ordering (always acquire locks in the same sequence) or use tryLock with timeouts. Deadlock is silent — no exception, no crash, just a hung thread pool and a pager at 3 AM.

The Java Memory Model (JMM) & The Visibility Problem

In a multi-core environment, threads don't just talk to main memory; they have local CPU caches. This creates a visibility problem: Thread A might update a variable in its cache, but Thread B on another core still sees the old value in main memory. The JMM defines the 'Happens-Before' relationship, ensuring that memory writes by one specific statement are visible to another specific statement. Without proper synchronization or the volatile keyword, the JVM is actually allowed to reorder your code for optimization, which can lead to disastrous results in concurrent execution.

Here's the thing: most engineers think volatile makes all reads see the latest write. That's true for simple reads, but for compound operations like count++, you still get a race. Volatile only guarantees visibility, not atomicity. If you're doing read-modify-write, you need AtomicInteger or synchronized.

The JMM also defines the happens-before rule for thread start and join: calling Thread.start() happens-before any action in the started thread. Similarly, all actions in a thread happen-before another thread successfully returns from Thread.join(). These rules let you safely share initialization data without explicit synchronization.

package io.thecodeforge.concurrency;

public class VisibilityDemo {
    // Without volatile, the 'running' thread might never see the update from main
    private static volatile boolean running = true;

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            while (running) {
                // The CPU might optimize this into an infinite loop without volatile
            }
            System.out.println("Worker thread stopped safely.");
        });

        worker.start();
        Thread.sleep(1000);
        
        System.out.println("Requesting stop...");
        running = false;
        worker.join();
    }
}

Locks, Monitors, and Synchronized Internals

Every object in Java is associated with a 'Monitor'. When a thread enters a synchronized block, it must acquire the lock on that monitor. If the lock is held, the thread enters a BLOCKED state. Under the hood, the JVM optimizes this using 'Biased Locking' (now mostly deprecated in newer JDKs), 'Lightweight Locking', and finally 'Heavyweight Locking' involving OS-level mutexes. Understanding this escalation helps you write code that avoids unnecessary lock contention.

But here's the reality: synchronized is not as expensive as many junior devs fear. For uncontended locks, the JIT can eliminate the lock entirely (lock elision). Contended locks are the problem — they cause thread context switches that kill throughput. That's why ReentrantLock with tryLock can be a better choice under high contention: it avoids the OS mutex path if the lock is quickly available.

Wait/notify must always be called within a synchronized context because they are based on the monitor. When you call wait(), the thread releases the monitor and goes to WAITING state. When notify() is called, it wakes one thread, which must re-acquire the monitor before proceeding. This mechanism is fundamental to producer-consumer patterns.

package io.thecodeforge.concurrency;

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

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

    public void safeTransfer() {
        try {
            // TryLock prevents the 'deadly embrace' where two threads wait forever
            if (lockA.tryLock(50, TimeUnit.MILLISECONDS)) {\n                try {\n                    if (lockB.tryLock(50, TimeUnit.MILLISECONDS)) {\n                        try {\n                            System.out.println(\"Securely accessed both resources.\");\n                        } finally {\n                            lockB.unlock();\n                        }\n                    }\n                } finally {\n                    lockA.unlock();\n                }\n            }\n        } catch (InterruptedException e) {\n            Thread.currentThread().interrupt();\n        }\n    }\n}",
        "output": "Securely accessed both resources."
      }

Locking Strategy Matrix: Synchronized vs ReentrantLock

Choosing the right locking mechanism is a common interview discussion and a critical production decision. The following matrix summarizes the key trade-offs between synchronized and ReentrantLock. Use this as a quick reference when designing concurrent code.

In production, start with synchronized for simplicity. If you need timeouts, interruptibility, or fairness, switch to ReentrantLock. If read-dominant workloads, consider ReentrantReadWriteLock. Always document the lock order to avoid deadlocks.

// Using synchronized (simple)
public synchronized void increment() { counter++; }

// Using ReentrantLock with timeout
private final ReentrantLock lock = new ReentrantLock(true); // fair
public boolean tryTransfer() {
    if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {\n        try {\n            // critical section\n            return true;\n        } finally {
            lock.unlock();
        }
    }
    return false;
}

Thread Lifecycle and States: From NEW to TERMINATED

A Java thread goes through six well-defined states: NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED. Understanding these states is critical for debugging production issues. When you take a thread dump, every thread's state tells a story.

NEW means the thread object exists but start() hasn't been called yet. RUNNABLE means it's executing or ready to execute (the JVM doesn't distinguish between running and runnable). BLOCKED means it's waiting for a monitor lock. WAITING means it entered via Object.wait(), Thread.join(), or LockSupport.park(). TIMED_WAITING is similar but with a timeout.

The mistake many make is thinking that a thread in RUNNABLE is actively using CPU. It might be stuck in a tight loop waiting for a flag that never changes — that's a liveness failure disguised as RUNNABLE. Always look at the stack trace, not just the state.

package io.thecodeforge.concurrency;

public class ThreadLifecycle {
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(() -> {
            try {
                Thread.sleep(5000);  // TIMED_WAITING
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        System.out.println("After creation: " + t.getState()); // NEW
        t.start();
        System.out.println("After start: " + t.getState()); // RUNNABLE
        Thread.sleep(100);
        System.out.println("During sleep: " + t.getState()); // TIMED_WAITING
        t.join();
        System.out.println("After join: " + t.getState()); // TERMINATED
    }
}

Visual Thread State Machine

Understanding thread state transitions is easier with a diagram. The following Mermaid state diagram shows the valid transitions between Java thread states. Each arrow is triggered by a specific action (e.g., start(), sleep(), acquire lock). Use this as a mental map when debugging thread dumps: trace the state back to the operation that caused it.

Deadlock Prevention and Detection: The Patterns That Save Your App

Deadlock is the most feared concurrency bug because it brings the system to a complete halt with no error message. It happens when two or more threads hold locks and wait indefinitely for locks held by each other. The classic example: Thread1 locks A, then tries B; Thread2 locks B, then tries A.

The Java approach to deadlock detection is via thread dumps — jstack or jcmd will automatically detect cycles and report 'Found one Java-level deadlock'. But detection is reactive. Prevention requires consistent lock ordering or using higher-level abstractions that avoid nested locks.

The real fix that senior engineers use is to minimize the number of locks held simultaneously. If you must hold multiple locks, always acquire them in the same order across all code paths. Also consider using tryLock with backoff — if you can't acquire all locks within a timeout, release everything and retry. This makes deadlock impossible because locks are never held forever waiting for another lock.

package io.thecodeforge.concurrency;

public class DeadlockDetector {
    private static final Object lock1 = new Object();
    private static final Object lock2 = new Object();

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

        Thread t2 = new Thread(() -> {
            synchronized (lock2) {
                System.out.println("Thread2: acquired lock2");
                try { Thread.sleep(50); } catch (InterruptedException e) {}
                synchronized (lock1) {
                    System.out.println("Thread2: acquired lock1");
                }
            }
        });

        t1.start();
        t2.start();
    }
}

Deadlock Prevention: Technical Reference Guide

This reference guide consolidates the essential rules, patterns, and tools for preventing deadlocks in production systems. Use it as a checklist during code reviews and architecture design.

1. Consistent Lock Ordering Define a global ordering for all locks and strictly follow it. Example: lock accounts by account ID (always lock lower ID first). Enforce this with automated linting or architecture tests.

2. tryLock with Timeout Replace indefinite synchronized blocks with ReentrantLock.tryLock(timeout). If you cannot acquire all locks within the timeout, release any locks already held and retry (with backoff). This guarantees that deadlock is impossible.

3. Lock Hierarchy Organize locks into a hierarchy (e.g., Layer1, Layer2) and always lock from highest to lowest. Code that violates the hierarchy should fail fast in tests.

4. Minimize Lock Scope Hold locks only for the minimal critical section. Never perform I/O, sleep, or call unknown code while holding a lock. This reduces the chance of lock contention and deadlock.

5. Avoid Nested Locks Whenever possible, use a single lock or higher-level abstractions (e.g., ConcurrentHashMap, atomic operations) that eliminate the need for multiple locks.

6. Deadlock Detection Tools jstack, jcmd, and VisualVM can detect deadlocks at runtime. Integrate ThreadMXBean.findDeadlockedThreads() into your health check endpoint to alert operations teams.

7. Code Review Checklist - Are all locks acquired in the same order? - Is there any path where a thread holds one lock and waits for another? - Are tryLock calls paired with rollback logic? - Is the lock scope minimised?

// Example: Lock ordering by account ID
public void transfer(Account from, Account to, int amount) {\n    // Always lock lower ID first to prevent deadlock\n    Object lock1 = from.getId() < to.getId() ? from : to;\n    Object lock2 = from.getId() < to.getId() ? to : from;\n    synchronized(lock1) {\n        synchronized(lock2) {\n            from.debit(amount);\n            to.credit(amount);\n        }
    }
}

Concurrency Utilities: From CountDownLatch to CompletableFuture

Raw threads and synchronized are the assembly language of concurrency. The java.util.concurrent package provides higher-level building blocks that handle common patterns safely and efficiently.

CountDownLatch lets one or more threads wait until a set of operations completes. CyclicBarrier lets a set of threads wait for each other to reach a common barrier point. Semaphore controls access to a pool of resources. Exchanger lets two threads exchange objects at a synchronization point.

But the workhorse in modern Java is CompletableFuture. It chains asynchronous tasks with thenApply, thenCompose, and exceptionally. It provides a declarative way to build async pipelines without nesting callbacks. When used with a ForkJoinPool, it can automatically parallelize independent stages.

The key production insight: CompletableFuture uses a default ForkJoinPool that is sized to the number of CPU cores. For I/O-bound tasks, this can starve CPU-bound work. Always supply a custom executor for I/O-heavy operations.

package io.thecodeforge.concurrency;

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class AsyncPipeline {
    private static final ExecutorService ioExecutor = Executors.newFixedThreadPool(20);

    public static void main(String[] args) {
        CompletableFuture.supplyAsync(() -> fetchUser(1), ioExecutor)
            .thenApplyAsync(user -> enrichProfile(user), ioExecutor)
            .thenAccept(profile -> sendNotification(profile))
            .exceptionally(e -> {
                System.err.println("Failed: " + e.getMessage());
                return null;
            });
    }

    private static String fetchUser(int id) {
        // Simulate IO call
        return "User_" + id;
    }

    private static String enrichProfile(String user) {
        return user + "_enriched";
    }

    private static void sendNotification(String profile) {
        System.out.println("Sent notification for " + profile);
    }
}

Concurrent Collection Performance Comparison

Choosing the right concurrent collection is critical for performance. The table below compares the most common java.util.concurrent collections across key dimensions: thread-safety, concurrency level, iteration semantics, and typical use cases.

What Is Multithreading and Why Multitasking Is a Lie

You've been asked to explain the difference between multitasking and multithreading in an interview. Here's the truth that matters after your third production outage. Multitasking is the OS-level illusion of running multiple processes simultaneously. The CPU juggles them so fast you think they're parallel. Multithreading is different — it's multiple threads of execution within a single process, sharing heap memory, stack frames be damned. Your JVM starts with one main thread. You spawn more to keep the UI responsive while a database query blocks, or to process a stream of orders without serializing latency. The critical distinction: threads share memory. Processes don't. That's why a deadlock in one thread crashes your entire app, not just the OS scheduler. When a junior asks 'why not just use processes?', you answer: context switching overhead and shared state. When they ask 'why not single-threaded?', show them the latency graph where one blocking call stalls 10,000 requests. That's the 'why'.

// io.thecodeforge.multithreading
// Demonstrates process vs thread memory isolation
public class MultitaskingLie {
    public static void main(String[] args) {
        // Shared mutable state — threads see each other
        int[] sharedCounter = {0};
        
        Runnable incrementTask = () -> {
            for (int i = 0; i < 1000; i++) {
                sharedCounter[0]++;  // no synchronization → data race
            }
        };
        
        Thread t1 = new Thread(incrementTask);
        Thread t2 = new Thread(incrementTask);
        t1.start();
        t2.start();
        
        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        
        System.out.println("Expected: 2000, Actual: " + sharedCounter[0]);
        // Output: Expected: 2000, Actual: 1342 (non-deterministic)
    }
}

Daemon vs User Threads: Which Gets Killed When JVM Shuts Down

Not all threads survive the JVM exit. User threads keep the process alive. Daemon threads are background workers that the JVM kills without mercy when no user threads remain. This is not optional — it's a feature your GC threads use. If you launch a background metrics uploader as a user thread, your app never terminates cleanly. The JVM will wait for it forever, leaking memory until someone kills -9 the PID. Conversely, if you mark it daemon, the JVM yanks it mid-execution when the main thread finishes. That means incomplete writes, lost data, corrupted files. The production pattern: daemon threads for tasks where losing work is acceptable (cache warmers, periodic stats). User threads for cleanup, flush, or commit operations. Set the daemon flag before calling start(). After start() it's a no-op that silently does nothing. Found that one the hard way during a rollout that took down an entire microservice because disk buffers never flushed.

// io.thecodeforge.multithreading
// Daemon threads terminate when all user threads finish
public class DaemonTrap {
    public static void main(String[] args) {
        Thread worker = new Thread(() -> {
            try {
                Thread.sleep(5000);  // Simulate slow flush
                System.out.println("Data flushed to disk");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        
        worker.setDaemon(true);  // Set BEFORE start
        worker.start();
        
        System.out.println("Main thread ending");
        // JVM exits before worker prints: no flush occurs
    }
}

Thread Priority: The OS Ignores You (Mostly)

You can call thread.setPriority(Thread.MAX_PRIORITY) and expect your thread to jump the queue. Reality: the JVM maps Java thread priorities to OS thread priorities in a lossy, platform-dependent way. Linux ignores them entirely for default scheduling policies. Windows honors a rough mapping but the kernel scheduler still makes its own decisions. Priority inversion is the real killer — a low-priority thread holds a lock a high-priority thread needs. The high-priority thread spins waiting, making the system appear frozen. Fix with ReentrantLock's fair mode or redesign to reduce shared lock contention. My rule: never rely on thread priorities for correctness. They're hints, not guarantees. Use them for soft optimization, like bumping a background log flusher so it doesn't starve the main request handler. But if your design breaks because a thread got the wrong priority, your design is wrong. Fix the locks, not the priority.

// io.thecodeforge.multithreading
// Priority inversion demonstrated
import java.util.concurrent.locks.ReentrantLock;

public class PriorityMyth {
    private static final ReentrantLock lock = new ReentrantLock();
    
    public static void main(String[] args) throws InterruptedException {
        Thread high = new Thread(() -> performCriticalTask(), "HIGH");
        Thread low = new Thread(() -> performCriticalTask(), "LOW");
        
        high.setPriority(Thread.MAX_PRIORITY);
        low.setPriority(Thread.MIN_PRIORITY);
        
        // Start low first to grab the lock
        low.start();
        Thread.sleep(100);  // Let low acquire lock
        high.start();  // Now high priority blocks on low — inversion
        
        // Output: LOW acquires lock, HIGH waits
    }
    
    private static void performCriticalTask() {
        lock.lock();
        try {
            System.out.println(Thread.currentThread().getName() + " acquired lock");
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            lock.unlock();
        }
    }
}