What Are the Thread States in Java?

Thread.State defines six states, and the lifecycle is worth being able to recite.

NEW is a thread that has been created but not yet started. RUNNABLE means the thread is running or is queued waiting for a CPU — the JVM lumps those two together, which surprises people who expect a separate running state. BLOCKED means the thread is waiting to enter a synchronized block or method because another thread holds the monitor. WAITING means the thread has called Object.wait, Thread.join or Thread.sleep with no timeout, and it is waiting to be notified. TIMED_WAITING is the same but with a deadline — a sleep with a timeout, or a join with a timeout. TERMINATED means the run method has returned or the thread died from an exception.

The transitions follow from the operations you perform. Calling start() moves NEW to RUNNABLE. A thread that tries to take a monitor someone else holds moves to BLOCKED, and it wakes to RUNNABLE when the monitor is released. A thread that calls wait() moves to WAITING, and the notifier's notify() moves it back to RUNNABLE. A thread that finishes moves to TERMINATED, and that is final.

Two distinctions interviewers like. WAITING and TIMED_WAITING are separate states even though the behaviour is similar, because one can end without anybody doing anything. And BLOCKED is not the same as WAITING — BLOCKED is about monitor contention, WAITING is about a deliberate hand-off, and they are resolved by different events.

Thread.getState() returns the current state, and ThreadMXBean gives you a snapshot of every live thread with its stack trace, which is what you actually want when you are diagnosing a stuck application.

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            try {
                Thread.sleep(80);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        worker.start();

        Thread.sleep(20);
        System.out.println("state while sleeping : " + worker.getState());

        worker.join();
        System.out.println("state after join    : " + worker.getState());

        Object lock = new Object();
        Thread waiter = new Thread(() -> {
            synchronized (lock) {
                try {
                    lock.wait(80);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
        waiter.start();
        Thread.sleep(20);
        System.out.println("state while waiting : " + waiter.getState());
        waiter.join();
        System.out.println("final state         : " + waiter.getState());
    }
}

The output maps the states to real situations. A thread inside Thread.sleep reports TIMED_WAITING, a thread that has finished reports TERMINATED, and a thread parked in Object.wait reports WAITING.

In practice the state tells you where to look next. A thread stuck in BLOCKED points at monitor contention, usually a lock held for too long. A thread in WAITING that never wakes points at a missed notification. A thread in TIMED_WAITING that should be making progress points at a slow downstream call. And a RUNNABLE thread with a huge stack of frames in a thread dump points at a hot loop rather than a deadlock.

The caveat is that RUNNABLE includes threads that are simply waiting for a CPU, so a thread dump full of RUNNABLE threads usually means the application is CPU-bound rather than stuck.

The two are different states and they point at different problems. A thread that wants to enter a synchronized block whose monitor is held by someone else reports BLOCKED. It is waiting for a lock, and it becomes runnable automatically the moment the monitor is released — nobody has to notify it, because the JVM handles the handover.

A thread that is inside a synchronized block and calls Object.wait() reports WAITING (or TIMED_WAITING if it passed a timeout). It has deliberately released the monitor and parked itself, and it will only become runnable when another thread calls notify or notifyAll on the same monitor, or when its timeout expires.

public class Main {
    public static void main(String[] args) throws InterruptedException {
        Object lock = new Object();
        java.util.concurrent.CountDownLatch waiterReady = new java.util.concurrent.CountDownLatch(1);
        java.util.concurrent.CountDownLatch blockerReady = new java.util.concurrent.CountDownLatch(1);

        // A thread waiting to be notified: it called wait().
        Thread waiter = new Thread(() -> {
            synchronized (lock) {
                waiterReady.countDown();
                try {
                    lock.wait(60);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        }, "waiter");
        waiter.start();
        waiterReady.await();
        Thread.sleep(20);
        System.out.println("waiter state  : " + waiter.getState());

        // A thread holding the monitor for a while.
        Thread blocker = new Thread(() -> {
            synchronized (lock) {
                blockerReady.countDown();
                try {
                    Thread.sleep(150);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        }, "blocker");
        blocker.start();
        blockerReady.await();

        // A thread waiting for that monitor: it wants a held lock.
        Thread blocked = new Thread(() -> {
            synchronized (lock) {
                System.out.println("the blocked thread finally runs");
            }
        }, "blocked");
        blocked.start();
        Thread.sleep(20);
        System.out.println("blocked state : " + blocked.getState());

        waiter.join();
        blocker.join();
        blocked.join();
        System.out.println("all finished");
    }
}

The output shows the two states side by side. The waiter is in WAITING because it parked itself with wait(). The blocked thread is in BLOCKED because the blocker still holds the monitor.

The practical difference shows up in how you fix them. A BLOCKED thread is fixed by making the critical section shorter or by reducing contention — the thread is not asleep, it is queued. A WAITING thread that never wakes is a bug in the notification logic: someone called wait without anyone else agreeing to notify, or a notify was sent before the waiter had started waiting.

There is a third case that is easy to confuse with both. A thread blocked on a lock that is not a monitor — one using ReentrantLock, or a thread in a LockSupport.park, or one waiting on a BlockingQueue — does not report BLOCKED at all. It reports WAITING or TIMED_WAITING. That is why a thread dump full of WAITING threads with no obvious monitor contention usually points at a queue or a condition variable rather than at synchronized code.