Java Thread Lifecycle — The 6 States
Fast recall
Quick revision
Core answer
Whether the candidate knows the exact Thread.State enum values and can explain the transitions that move a thread between states
Conflating RUNNABLE with 'currently executing on a CPU' — RUNNABLE includes both 'ready to run' and 'actually running' because Java does not distinguish between the two at the API level
Explain that BLOCKED is specifically about waiting for a monitor lock, while WAITING and TIMED_WAITING are about explicit coordination (wait/join/park). Also mention that thread dumps show these states, making them essential for production debugging.
Interview-ready guide
Interview answer
Java defines six thread states in Thread.State — and the most important thing to know is that RUNNABLE does not mean currently executing.
States:
- NEW: before
start()is called - RUNNABLE: eligible for CPU time — may or may not be actively running; there is no separate RUNNING state in the Java enum
- BLOCKED: waiting for a
synchronizedmonitor held by another thread - WAITING: called
wait(),join(), orpark()without a timeout — deliberately parked until signaled - TIMED_WAITING: same but with a timeout —
sleep(),wait(millis) - TERMINATED:
run()completed; cannot be restarted — callingstart()again throwsIllegalThreadStateException
Debugging significance:
- BLOCKED threads all pointing to the same monitor → lock contention; the lock-holder is shown in the dump
- Repeated identical RUNNABLE stacks → CPU-burning loop or spin
- WAITING threads → typically correct producer-consumer pattern
I recommend focusing on the BLOCKED vs WAITING distinction when reading thread dumps — it tells you whether you have a locking problem or a design-level wait.
Java Thread Lifecycle — The 6 States
Direct Answer
A Java thread has 6 states defined in Thread.State: NEW (created, not started), RUNNABLE (executing or ready to execute), BLOCKED (waiting for a monitor lock), WAITING (waiting indefinitely for another thread), TIMED_WAITING (waiting with a timeout), and TERMINATED (finished execution).
Deep Dive & Architecture
A thread is an independent path of execution within a JVM process, sharing heap memory but having its own stack and program counter.
Java threads are 1:1 mapped to OS native threads on all mainstream JVMs (HotSpot, OpenJ9) — each platform thread costs ~0.5–1 MB of stack memory and is scheduled by the OS.
You create them by implementing Runnable (preferred — preserves your single inheritance slot and works with ExecutorService) or extending Thread (legacy). Multithreading pays off for three workloads: CPU-bound parallelism (dividing work across cores), I/O concurrency (overlapping waits), and responsiveness (keeping UI/event loops free). As of Java 21, virtual threads (Project Loom) give you millions of cheap, JVM-scheduled threads ideal for I/O-bound servers.
Thinking threads have separate memory — they share heap. Calling thread.run() instead of thread.start() and wondering why everything runs on the main thread
Common Mistakes & Pitfalls
Conflating RUNNABLE with 'currently executing on a CPU' — RUNNABLE includes both 'ready to run' and 'actually running' because Java does not distinguish between the two at the API level
Check your understanding
Answer these without looking back at the article.
- What are daemon threads in Java and how do they differ from user threads?
- How does thread interruption work in Java? Explain `interrupt()`, `isInterrupted()`, and `interrupted()`, and the correct way to respond to interrupts.
- What is a thread in Java? Explain the `Thread` class vs `Runnable`, how threads map to OS threads, and when multithreading pays off.
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.