Thread States and Sleeping in Java SE 25
These eleven questions cover scheduling, interruption, and waiting. Java's thread-state model distinguishes blocked and waiting threads without defining a separate sleeping state.
What happens to a thread's state when start is called?
Answer: Start schedules a NEW thread to execute. It becomes eligible to run, represented by RUNNABLE. However, a subsequent getState call is only a snapshot: a fast task may already have terminated or reached a blocking operation before the caller observes it.
Do not write a test that assumes getState immediately after start must return RUNNABLE. Use coordination to establish a condition you need to observe, and use join to wait for termination. Starting an already started thread is illegal, even if it has since completed.
Which Java state represents a thread that is ready to execute?
Answer: RUNNABLE. It includes both execution in the JVM and eligibility to execute while waiting for processor or other operating-system resources. Java does not expose separate READY and RUNNING enum values.
The six Thread.State values are NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED. They describe JVM-level states, not an exact operating-system scheduling model. Several threads can be RUNNABLE simultaneously, including several that are executing on different cores.
Which states prevent a live thread from making ordinary execution progress?
Answer: BLOCKED indicates waiting to acquire an intrinsic monitor. WAITING indicates an indefinite wait for another action, such as untimed Object.wait or Thread.join. TIMED_WAITING indicates a timed wait, including Thread.sleep and timed variants of wait or join.
NEW and TERMINATED threads are also not executing, but they are not live threads waiting to resume an existing task. A notified Object.wait caller may have to contend for the monitor before continuing. State transitions are observations, not a mechanism for waking a thread or establishing memory visibility.
Are Thread.sleep and Thread.yield static methods?
Answer: Yes. They affect the currently executing thread, not some other Thread object. Write
Thread.sleep(100)andThread.yield()to make that clear. Calling a static method through a thread variable is misleading and does not make that variable's thread sleep or yield.Sleep pauses for a requested duration subject to interruption and scheduling precision. Yield is only a scheduling hint and may be ignored. Neither releases an intrinsic monitor the current thread holds, and neither should be used to guarantee another thread gets a turn.
When does a thread enter TERMINATED?
Answer: It enters TERMINATED after its execution completes, whether its task returns normally or ends because of an uncaught exception. The Thread object can remain reachable after execution has ended.
An interrupt request alone does not imply termination; a task may handle it and continue, or ignore it entirely. To determine that execution has finished, join the thread or use a suitable task-completion mechanism. An uncaught failure in one worker also does not automatically mean that every other thread or the whole application terminates.
When is Thread.sleep useful?
Answer: Sleep can express a delay for pacing, a simple backoff, or a simulation. It does not prove that another thread has completed work, released a lock, or published data. Use coordination primitives for those requirements.
For recurring or delayed jobs, a ScheduledExecutorService often communicates the scheduling requirement better. Avoid sleeping while holding a lock: the thread retains the monitor, potentially delaying other work. Sleep also does not make CPU-intensive work scale better merely by inserting pauses between calculations.
Must InterruptedException from sleep always be caught locally?
Answer: No. It must be caught or declared, because it is checked. If a method can propagate interruption, declare InterruptedException. A Runnable's run method cannot declare it, so the task typically catches it, restores the interrupt status when appropriate, and returns.
import java.util.concurrent.CountDownLatch; public class InterruptiblePause { public static void main(String[] args) throws InterruptedException { var started = new CountDownLatch(1); Thread worker = new Thread(() -> { started.countDown(); try { Thread.sleep(60_000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); System.out.println("Cancellation received"); } }); worker.start(); started.await(); worker.interrupt(); worker.join(); } }The worker responds whether interruption arrives just before sleep or while sleeping. Sleep clears interrupt status when it throws InterruptedException; the catch restores it. There is no assumption that an arbitrary short delay is enough to let the worker start.
Does waking a waiting thread make it execute immediately?
Answer: No. Ending a wait can make a thread eligible to continue, but it still needs execution resources. A thread returning from Object.wait must first reacquire that object's monitor, and another thread may acquire it first.
A notification is not a transfer of monitor ownership. The notifying thread continues holding the monitor until it releases it. Recheck a waited-for condition in a loop after waking, because notification, spurious wakeups, and competing consumers do not guarantee the condition remains satisfied.
Is Thread.sleep an exact timer?
Answer: No. Timing depends on timer precision and scheduling. When a requested sleep expires, the thread is eligible to continue but may resume later. Interruption can end the sleep with an exception before the requested interval has elapsed.
Do not use elapsed sleep time as evidence that a separate operation has completed. A zero duration is permitted but provides no reliable handoff to another thread. A negative millisecond argument to sleep(long) is invalid; the overload accepting a Duration treats a negative duration as a no-op. For measuring elapsed time, use System.nanoTime and compare differences rather than relying on wall-clock adjustments.
Can thread priority guarantee responsiveness or execution order?
Answer: No. Platform-thread priorities range from 1 through 10, but their scheduling effect is platform-dependent. Raising a priority is not a substitute for bounded work, avoiding contention, or supplying enough execution capacity.
Virtual threads have a fixed priority of Thread.NORM_PRIORITY, which is 5; a valid setPriority call does not change it. Design correctness independently of priorities. If latency matters, measure the workload and address its bottlenecks rather than depending on an assumed scheduling preference.
What is the difference between TIMED_WAITING and sleeping?
Answer: TIMED_WAITING is a Thread.State value; sleeping is one operation that can cause that state. Java has no separate SLEEP or SLEEPING enum value. Other causes include timed Object.wait and timed Thread.join, so observing TIMED_WAITING alone does not identify what the thread is doing.
Sleep retains held monitors and can be interrupted. Object.wait releases the monitor of the object being waited on, then reacquires it before returning. Notify and notifyAll affect that object's waiters; they do not wake a thread merely because it called Thread.sleep. These distinctions correct the common but misleading idea that âsleepingâ and âtimed waitingâ are mutually exclusive states.
References: Thread.State, Thread timing and interruption, and Object.wait.