All topics
5 / 101
multi threading
intermediate

Thread Lifecycle

Know the six states a Java thread moves through, and what causes each transition.

A Java thread moves through six states in its life. Knowing them matters for one practical reason: when production hangs, you take a thread dump, and the states tell you what is wrong.

A guest at a restaurant — arrived (NEW), seated and eating (RUNNABLE), waiting for the bathroom (BLOCKED), waiting for a friend (WAITING), nap with an alarm (TIMED_WAITING), left (TERMINATED).

Key Concepts

1
The six states.
  NEW             created, not started yet
  RUNNABLE        running, or ready to run
  BLOCKED         waiting to get into a synchronized block
  WAITING         waiting for another thread to signal it
  TIMED_WAITING   same, but with a timeout (sleep, wait(1000))
  TERMINATED      finished
2
BLOCKED versus WAITING is the distinction that pays. They sound similar and mean different things.
3
BLOCKED means another thread is holding a lock this one wants. That is contention, and the dump names both the lock and its owner.
4
WAITING means this thread asked to be paused until somebody wakes it. Nobody is holding anything. The question becomes: who was supposed to signal it, and why didn't they?
5
In a hung service, a wall of BLOCKED threads points to a lock someone is holding too long. A wall of WAITING threads points to an empty pool or a callback that never fired.
6
RUNNABLE does not mean running. Java cannot tell the difference between a thread using the processor and a thread waiting for a network reply, so both show as RUNNABLE.
7
A dump full of RUNNABLE threads sitting in socketRead0 is not a busy application. It is an application waiting on something slow downstream. This gets misdiagnosed often.
socketRead0
8
start() and run() are not the same. start() asks the JVM for a new thread and runs your code on it. run() just calls the method on the current thread — no thread is created, nothing runs in parallel, and nothing warns you.
start()run()
9
Calling start() twice throws. A thread cannot be restarted, which is exactly why thread pools exist.
start()
10
Stopping a thread is a request, not a command. interrupt() sets a flag. A thread sleeping or waiting throws InterruptedException, and the flag is cleared.
interrupt()InterruptedException
11
That last part is what people miss:
12
    try {
        work();
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();   // put the flag back
        return;                                // and stop
    }
13
Without restoring the flag, code further up that checks for interruption sees nothing, and the cancellation silently disappears.
14
Thread.stop() exists and is deprecated. It releases locks at an arbitrary point, leaving shared data half modified.
Thread.stop()
15
What the interviewer is probing.1. "Name the thread states." Probing: recall plus the useful distinction. Stalls: listing five. Moves up: six, with BLOCKED versus WAITING explained rather than listed.
16
2. "start() or run()?" Probing: the classic trap. Stalls: "Both run the thread." Moves up: run() creates no thread; start() twice throws.
start()run()
17
3. "A dump is full of BLOCKED threads." Probing: diagnosis. Stalls: "They are waiting." Moves up: lock contention; find the owner named in the dump.
18
4. "How do you stop a thread?" Probing: cooperative cancellation. Stalls: "Thread.stop()." Moves up: interrupt plus a loop that checks the flag; stop() leaves data half-updated.
Thread.stop()stop()
19
5. "You caught InterruptedException. Now what?" Probing: the cleared flag. Stalls: log and carry on. Moves up: restore it or propagate, or the cancellation is lost.
InterruptedException
20
  States and what a dump is telling you
21
  State          Cause                           What to look at
  ------------------------------------------------------------------
  NEW            created, not started            -
  RUNNABLE       executing, waiting for CPU,     CPU profile; check
                 OR blocked on IO                for socketRead0
  BLOCKED        waiting for a monitor           the lock owner named
                                                 in the dump
  WAITING        wait(), join(), park()          who should signal?
  TIMED_WAITING  sleep(n), wait(n), join(n),     usually benign
                 parkNanos
  TERMINATED     run() finished or threw         -
22
  Reading a hang
    many BLOCKED on one lock       -> contention; find the owner
    many WAITING on a condition    -> a pool exhausted, or a callback
                                      that never fired
    many RUNNABLE in socketRead0   -> downstream IO is slow, not CPU
    one thread RUNNABLE, 100% CPU  -> a spin or an infinite loop
23
  Cooperative cancellation, correctly
24
    while (!Thread.currentThread().isInterrupted()) {
        try {
            work();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();   // restore the flag
            break;                                 // then stop
        }
    }
25
  Why the restore matters
    Throwing InterruptedException CLEARS the interrupt flag. Code
    further up the stack that checks isInterrupted() would see false
    and keep working -- the cancellation silently disappears.
Use cases:ThreadsDebuggingLifecycle