Java Thread States — Lock During I/O Causes BLOCKED

Every production outage involving threads — the deadlock that froze your payment service at 2 AM, the thread pool that silently starved under load, the race condition that corrupted user data — traces back to a misunderstanding of what a thread is actually doing at any given moment. The Java thread lifecycle isn't just an academic diagram you memorize for interviews. It's the mental model that lets you read a thread dump, diagnose a hung application, and design concurrent systems that hold up under real traffic.

The problem is that most resources treat the lifecycle as a static state machine — here are the six boxes, here are the arrows, done. But threads don't live in boxes. They transition between states in ways that depend on OS scheduling, JVM implementation details, monitor ownership, and the specific flavor of waiting you've asked them to do. Miss those nuances and you'll write code that looks correct, passes unit tests, and then silently misbehaves in production with 200 concurrent users.

By the end of this article you'll be able to read a real thread dump and know exactly what each thread is doing and why. You'll understand the difference between BLOCKED and WAITING at the JVM level — not just the textbook definition. You'll know which state transitions are guaranteed, which are platform-dependent, and which ones hide the bugs that take senior engineers days to find. Let's build that mental model from the ground up.

The 6 Thread States — What Each Actually Means

Java defines six thread states in java.lang.Thread.State. They're not just labels — each maps to a specific JVM or OS condition.

• NEW: Thread created but start() not called. Not yet alive.
• RUNNABLE: Thread is executing in the JVM (or ready to execute, waiting for CPU). Includes both running and ready-to-run.
• BLOCKED: Thread is waiting for a monitor lock to enter a synchronized block/method.
• WAITING: Thread is waiting indefinitely for another thread to perform a specific action (e.g., wait(), join(), park()).
• TIMED_WAITING: Same as WAITING but with a timeout (sleep, wait(timeout), join(timeout), parkNanos).
• TERMINATED: Thread has completed (run() finished or exception).

The key insight: RUNNABLE does not mean 'using CPU right now'. It means the thread is eligible for scheduling. The OS decides when it actually runs. This is why busy-wait loops (while(!flag)) keep a thread in RUNNABLE but waste CPU.

package io.thecodeforge.thread;

public class ThreadStateDemo {
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(() -> {
            // thread will be RUNNABLE during execution
            try {
                Thread.sleep(1000); // TIMED_WAITING
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }, "demo-thread");

        System.out.println("After creation: " + t.getState()); // NEW
        t.start();
        System.out.println("After start: " + t.getState()); // RUNNABLE
        Thread.sleep(200);
        System.out.println("Mid-sleep: " + t.getState()); // TIMED_WAITING
        t.join();
        System.out.println("After join: " + t.getState()); // TERMINATED
    }
}

State Transitions — The Arrows Between the Boxes

Threads don't jump randomly. Each transition has a trigger:

• NEW → RUNNABLE: Calling start().
• RUNNABLE → BLOCKED: Attempting to enter a synchronized block/method without the lock. JVM puts you on the monitor's entry set.
• BLOCKED → RUNNABLE: The lock holder releases the lock (exits synchronized block).
• RUNNABLE → WAITING: Calling Object.wait(), Thread.join(), or LockSupport.park(). Thread is put in the wait set of the monitor.
• WAITING → RUNNABLE: Another thread calls notify()/notifyAll() on the same monitor, or the thread is interrupted. But the thread must re-acquire the lock before proceeding — so it goes to BLOCKED first, then RUNNABLE.
• RUNNABLE → TIMED_WAITING: Thread.sleep(time), wait(timeout), join(timeout), parkNanos().
• TIMED_WAITING → RUNNABLE: Timeout expires, or notify/interrupt.
• RUNNABLE → TERMINATED: run() completes.

The critical detail: after notify(), the waiting thread doesn't run immediately. It must re-acquire the monitor lock. This is why waiting code should always loop on the condition (spurious wakeup).

package io.thecodeforge.thread;

public class TransitionDemo {
    private static final Object lock = new Object();
    private static boolean ready = false;

    public static void main(String[] args) throws InterruptedException {
        Thread waiter = new Thread(() -> {
            synchronized (lock) {
                while (!ready) { // must loop
                    try {
                        lock.wait(); // RUNNABLE -> WAITING
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                    }
                }
                System.out.println("Condition met!");
            }
        }, "waiter");
        waiter.start();
        Thread.sleep(500); // let waiter get to WAITING
        System.out.println("Waiter state: " + waiter.getState()); // WAITING

        Thread notifier = new Thread(() -> {
            synchronized (lock) {
                ready = true;
                lock.notify(); // transition: WAITING -> BLOCKED -> RUNNABLE
            }
        }, "notifier");
        notifier.start();
        waiter.join();
        System.out.println("Final state: " + waiter.getState()); // TERMINATED
    }
}

BLOCKED vs WAITING — The JVM Difference

At the JVM level, BLOCKED and WAITING are distinct in the thread dump output:

• BLOCKED (on object monitor): The thread is in the entry set of a monitor, waiting to acquire the lock. The dump shows which lock and which thread holds it.
• WAITING (on object monitor): The thread is in the wait set, having called wait() on that monitor. The dump shows 'waiting on <monitor>' but not who will wake it.
• WAITING (parking): Thread used LockSupport.park() — typically from java.util.concurrent (e.g., ForkJoinPool workers, CompletableFuture).

The performance impact: A BLOCKED thread consumes no CPU but the OS keeps it in the scheduler's run queue (it's legally runnable but the JVM won't let it). In contrast, a WAITING thread is typically descheduled until notified. Both are 'idle' but the reason matters for debugging.

A thread dump might show hundreds of BLOCKED threads all waiting on the same lock — that's a contention hotspot. WAITING threads on the same condition often indicate a missing notify. WAITING threads with 'parking' are usually normal (thread pool idle).

package io.thecodeforge.thread;

public class BlockedVsWaiting {
    private static final Object lock = new Object();

    public static void main(String[] args) throws InterruptedException {
        // Thread that holds the lock forever
        Thread holder = new Thread(() -> {
            synchronized (lock) {
                try {
                    Thread.sleep(10000); // holds lock while sleeping
                } catch (InterruptedException e) {}
            }
        }, "holder");

        // Thread that blocks trying to get lock
        Thread blocker = new Thread(() -> {
            synchronized (lock) { // will be BLOCKED
                System.out.println("Never prints");
            }
        }, "blocker");

        // Thread that waits on the same lock (after notify, it would block)
        Thread waiter = new Thread(() -> {
            synchronized (lock) {
                try {
                    lock.wait(); // WAITING
                } catch (InterruptedException e) {}
            }
        }, "waiter");

        holder.start();
        Thread.sleep(100);
        blocker.start();
        waiter.start();
        Thread.sleep(100);

        System.out.println("Holder: " + holder.getState());    // TIMED_WAITING (sleep)
        System.out.println("Blocker: " + blocker.getState());  // BLOCKED
        System.out.println("Waiter: " + waiter.getState());     // WAITING

        System.exit(0);
    }
}

Thread Dump Analysis — Reading the Lifecycle in Action

When a production incident hits, your first tool is the thread dump. Here's what you're looking for:

• Thread name: Often configured in thread pools. 'http-nio-8080-exec-1' indicates a Tomcat worker.
• State: One of the six above.
• Stack trace: Shows exactly where the thread is blocked.
• Lock details: 'waiting for <0x00000007>', 'locked <0x00000008>'. The hex ID identifies the monitor.

Key patterns to recognize:

1. Deadlock: Thread A holds lock L1 and wants L2. Thread B holds L2 and wants L1. Both are BLOCKED. The dump explicitly says 'Found one Java-level deadlock'.
2. Lock contention: Many threads BLOCKED on the same lock, one owner.
3. Missed signal: Threads WAITING on a condition, nobody holding the lock.
4. Spinning: Thread state is RUNNABLE but the stack trace shows a tight loop (while(!flag){ } ) — consumes CPU without progress.

# Capture thread dump without killing the process
jstack -l <pid> > /tmp/threaddump_$(date +%s).txt

# Quick scan for BLOCKED threads
grep -E 'BLOCKED|WAITING \(on object monitor\)' /tmp/threaddump_*.txt

# Identify deadlocks explicitly
grep -A 10 'Found one Java-level deadlock' /tmp/threaddump_*.txt

# See which threads hold which locks
grep -E 'locked <|waiting for <' /tmp/threaddump_*.txt

# Count threads per state
awk '/java.lang.Thread.State:/{state=$3; count[state]++} END{for(s in count) print s, count[s]}' /tmp/threaddump_*.txt

# Example output:
# RUNNABLE 12
# BLOCKED 4
# WAITING 3
# TIMED_WAITING 2
# TERMINATED 0
# Expected: healthy pool can have many TIMED_WAITING (idle) and some RUNNABLE

Common Pitfalls and How to Avoid Them

Even experienced engineers fall into these traps. Here are the most common production failures linked to thread lifecycle misunderstanding:

Pitfall 1: Holding a lock during I/O A synchronized block wrapping a database call or HTTP request. If the external call hangs, every other thread wanting that lock is stuck in BLOCKED. Fix: Move I/O outside the synchronized block, or use a read/write lock, or apply a timeout on the I/O and recheck inside.

Pitfall 2: Notify without state flag Calling notify() but forgetting to set a condition variable that the waiting thread checks. The waiting thread wakes, checks the condition, finds it false, and goes back to WAITING — never to be woken again. Fix: Always use a boolean flag in conjunction with wait/notify.

Pitfall 3: Calling start() twice Thread.start() can only be called once. A second call throws IllegalThreadStateException. This happens often when reusing a thread object. Fix: Create a new Thread instance for each execution.

Pitfall 4: Assuming RUNNABLE means 'working' Resource exhaustion may cause many threads to be in RUNNABLE but not progressing because they're waiting on CPU scheduling. Monitoring tools that only show thread count in RUNNABLE can mislead. Fix: Combine thread dump with CPU profiling (jstack + top -H).

Pitfall 5: Ignoring interrupted flag When InterruptedException is caught, forgetting to restore the interrupt flag (Thread.currentThread().interrupt()) can cause the thread to miss shutdown signals. Fix: Always preserve the interrupt status in catch blocks.

package io.thecodeforge.thread;

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

public class PitfallExample {
    private final Lock lock = new ReentrantLock();

    public void doSomethingWithTimeout() throws InterruptedException {
        // Pitfall 1: holding lock during I/O fixed by tryLock with timeout
        if (lock.tryLock(1, TimeUnit.SECONDS)) {
            try {
                // do fast work, then release lock before I/O
                localFastWork();
            } finally {
                lock.unlock();
            }
            // now do I/O without holding lock
            externalCallWithTimeout();
        } else {
            throw new RuntimeException("Could not acquire lock within timeout");
        }
    }

    private void localFastWork() {
        // synchronous fast operations
    }

    private void externalCallWithTimeout() throws InterruptedException {
        // simulate with timeout
        Thread.sleep(200); // normally a URL connection with read timeout
    }

    // Pitfall 3: never call start() twice
    public static void main(String[] args) {
        Thread t = new Thread(() -> {});
        t.start();
        // t.start(); // throws IllegalThreadStateException
        Thread t2 = new Thread(() -> {});
        t2.start(); // always create new thread
    }
}