In a jstack thread dump, what do the thread states RUNNABLE, BLOCKED, WAITING and TIMED_WAITING mean, and what does each tell you during triage?

## Background: thread states and locks The JVM models each thread with a **state** from the `Thread.State` enum. A jstack dump prints this state on the line `java.lang.Thread.State: ...` for every thread, right above its stack trace. Understanding the four runtime states is the core skill of reading a dump. Two lock concepts appear in dumps: - A **monitor** (intrinsic lock) is the lock acquired by Java's `synchronized` keyword. Exactly one thread can own a given object's monitor at a time. - An **ownable synchronizer** is the lock used by `java.util.concurrent` (e.g. `ReentrantLock`), built on `LockSupport.park`. With `jstack -l` the dump also lists these. ## The four states ### RUNNABLE The thread is **running on a CPU or ready to run** (the OS may be time-slicing it). This is the only state that actually burns CPU. **Gotcha:** the JVM marks a thread RUNNABLE even when it is blocked deep inside a *native* call such as a socket `read()` — the JVM can't see past the native boundary, so a thread sitting idle on `socketRead0` still shows RUNNABLE. So RUNNABLE does not always mean 'busy'; check the actual stack frame. ### BLOCKED The thread is **waiting to enter a `synchronized` block/method** whose monitor another thread holds. The dump shows a line like `waiting to lock <0x...> (a com.example.Cache)` and, ideally, which thread is `locked` that same monitor. **Many threads BLOCKED on one monitor = lock contention**: they are serialized behind a hot critical section. This is the classic scalability bottleneck. ### WAITING The thread **voluntarily parked itself with no timeout** and will resume only when another thread signals it. It got here via `Object.wait()` (waiting on a `notify`), `Thread.join()` (waiting for another thread to die), `LockSupport.park()`, or `Condition.await()`. The dump shows `waiting on <0x...>` or `parking to wait for <0x...>`. A pool of worker threads idle for work legitimately sits in WAITING — that's normal. WAITING is suspicious only when a thread should be making progress but isn't. ### TIMED_WAITING Identical to WAITING but with a **deadline**, so it wakes on its own even if nobody signals it: `Thread.sleep(ms)`, timed `Object.wait(ms)`, `LockSupport.parkNanos`, `BlockingQueue.poll(timeout)`, thread-pool keep-alive. Seeing pool threads here between tasks is healthy. ### (The non-runtime states) NEW (not started) and TERMINATED (finished) also exist but rarely appear usefully in a dump. ## Reading states during triage | Symptom in the dump | Likely meaning | |---|---| | Many threads **BLOCKED** on the same monitor | Lock contention; one thread holds a hot lock | | Many threads **WAITING** to borrow from a pool | Connection/thread-pool exhaustion downstream | | One **RUNNABLE** thread in your method across several dumps | The CPU-burning hot loop | | Two threads each **BLOCKED** waiting on a lock the other holds | Deadlock (jstack labels it explicitly) | | Everything **WAITING/TIMED_WAITING**, app idle | Normal quiescent pool, or upstream starved it | **Key rule:** WAITING and TIMED_WAITING threads consume **no CPU**. If CPU is pegged, look only at RUNNABLE threads (and remember the native-I/O caveat). To distinguish a genuinely stuck thread from a momentary pause, take **several dumps a few seconds apart**: a thread on the *same* frame in every dump is stuck; one that moves is just busy doing work.