Thread States

1Concept / Definition

Every Java thread is at any moment in exactly one of six states defined by java.lang.Thread.State: NEW (created, not started), RUNNABLE (executing or ready to execute in the JVM), BLOCKED (waiting to enter a synchronized monitor), WAITING (waiting indefinitely for another thread's action), TIMED_WAITING (waiting with a timeout) and TERMINATED (finished). The states are JVM-level abstractions used by Thread.getState(), thread dumps and monitoring tools; they do not map one-to-one to operating-system thread states.

2Why It Exists

Knowing a thread's state is the first step in diagnosing hangs, slowdowns and deadlocks: a pool full of BLOCKED threads indicates lock contention, WAITING threads in a queue indicate idle workers or waits for results, RUNNABLE threads in socket reads indicate slow downstreams. The state model also documents the precise semantics of each blocking method.

3Core Concepts

NEW

A Thread object has been created but start() has not been called. No OS thread exists yet. Calling start() a second time on any thread (in any state after NEW) throws IllegalThreadStateException.

RUNNABLE

• The thread is executing Java code, or is ready and waiting for the OS to give it a CPU.
• It is also RUNNABLE while executing native code — including blocking socket reads, file I/O and many system calls — because the JVM does not know whether native code is waiting.
• Therefore: RUNNABLE ≠ consuming CPU. Combine thread dumps with per-thread CPU (top -H, cpu= in dumps) to tell busy from blocked in I/O.

BLOCKED

The thread is waiting to acquire an intrinsic monitor — entering a synchronized block or method whose monitor another thread holds — or to re-acquire the monitor after Object.wait() returns. BLOCKED applies only to monitors; threads waiting for java.util.concurrent locks are WAITING (they are parked).

WAITING

• Object.wait() without timeout (after releasing the monitor), until notify/notifyAll or interruption.
• Thread.join() without timeout, until the target thread terminates.
• LockSupport.park() — used by ReentrantLock, Condition.await(), BlockingQueue.take(), CountDownLatch.await(), Future.get(), until unpark or interruption.
• Idle pool threads waiting in take() are WAITING — normal, not a problem.

TIMED_WAITING

• Thread.sleep(millis) / sleep(Duration).
• Object.wait(timeout), Thread.join(timeout) / join(Duration).
• LockSupport.parkNanos / parkUntil — used by tryLock(timeout), poll(timeout), await(timeout), Future.get(timeout).
• Scheduled executor threads between tasks and pool threads with keep-alive timeouts.

TERMINATED

run() has completed, normally or by throwing an exception (after the uncaught-exception handler ran). The OS thread is gone; the Thread object remains as long as it is referenced. join() on a terminated thread returns immediately.

4How It Works Internally

HotSpot tracks a lower-level thread state (in Java, in VM, in native, blocked) for safepoints, and separately maintains the java.lang.Thread status field that getState() reports. Monitor contention sets BLOCKED around ObjectMonitor::enter; parking sets WAITING/TIMED_WAITING around Parker::park. Virtual threads have the same states; a blocked virtual thread is unmounted from its carrier and does not occupy an OS thread.

5APIs / Features / Syntax

Object lock = new Object();
Thread holder = Thread.ofPlatform().start(() -> { synchronized (lock) { sleepQuietly(5_000); } });
Thread.sleep(100);
Thread contender = Thread.ofPlatform().start(() -> { synchronized (lock) { } });
Thread waiter = Thread.ofPlatform().start(() -> LockSupport.park());
Thread.sleep(100);
// TIMED_WAITING  (sleeping while holding the lock)
System.out.println(holder.getState());
System.out.println(contender.getState());  // BLOCKED        (wants the monitor)
System.out.println(waiter.getState());      // WAITING        (parked)

// Counting states across the JVM
Map<Thread.State, Long> byState = Thread.getAllStackTraces().keySet().stream()
        .collect(Collectors.groupingBy(Thread::getState, Collectors.counting()));

# States in a thread dump (Volume III 5.2)
$ jcmd <pid> Thread.print | grep -o "State: [A-Z_]*" | sort | uniq -c
    212 State: RUNNABLE
     48 State: TIMED_WAITING
    180 State: WAITING
     37 State: BLOCKED           ← contention on some monitor: find "waiting to lock <0x…>"

6Practical Examples

7Common Problems & Mistakes

• Reading RUNNABLE as 'working' — it includes blocking native I/O.
• Expecting BLOCKED for ReentrantLock waits — they show as WAITING (parked) with 'parking to wait for'.
• Treating many WAITING threads as a problem — idle pools look like that.
• Using getState() for synchronisation logic — states are for monitoring only and change immediately.

8Performance & Production Considerations

• Export thread counts by state (jvm_threads_states_threads{state=…}) and alert on BLOCKED spikes.
• Always use timeouts on join, get, poll and lock acquisition in production paths to avoid indefinite WAITING.
• Name threads so state statistics can be grouped by pool.

Taking state snapshots is cheap but not free. A full thread dump brings the JVM to a safepoint and walks every stack, which pauses all threads for milliseconds with a few hundred threads and longer with thousands, so take dumps on demand or every few seconds during an incident, not continuously. Thread.getAllStackTraces and ThreadMXBean.dumpAllThreads have the same cost. For trends, rely on per-state gauges, which only read the status field, and on JFR events such as jdk.JavaMonitorEnter and jdk.ThreadPark, which record waits above a threshold together with the lock involved and the stack, at low overhead.

9Architecture & Design Considerations

Thread states turn into design rules once you look at what each state means for a shared resource. Every thread in BLOCKED or WAITING holds memory and often a pool slot while doing nothing, so a design that lets threads wait without a bound converts any slow dependency into exhaustion of the caller. Bound every wait with a timeout, size pools against downstream capacity rather than against expected load, and isolate dependencies in separate pools or bulkheads so that one slow service cannot leave every request thread waiting.

Contention shows up as BLOCKED or parked threads on one lock, and it is a design smell rather than a tuning problem: shrink critical sections, partition state, or replace a shared lock with concurrent structures or message passing. With virtual threads, WAITING becomes cheap because a parked virtual thread releases its carrier, which favours simple blocking code; the limits then move to connection pools and downstream rate limits, which need explicit semaphores. Finally, make states observable by design: name every pool, export per-state counts per pool and alert on sustained BLOCKED growth.

10Interview Questions & Answers