Thread lifecycle.

Think of a thread like a worker in a factory: interviewers ask this because they want to know if you understand the worker's whole day, not just the moments when it is busy.

Question: What is the thread lifecycle in Java?

Answer: In Java, a thread moves through states such as NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, and TERMINATED. A thread is NEW before start(); after start() it becomes RUNNABLE, which means it can run, not that it is definitely on the CPU right now. It can then pause for a lock, another thread, or a timeout, and finally ends in TERMINATED when run() finishes.

Interview-Ready Answer: I’d explain it this way: a Java thread starts in NEW, moves to RUNNABLE after start(), and then may temporarily go to BLOCKED, WAITING, or TIMED_WAITING depending on whether it is fighting for a monitor lock, waiting indefinitely, or waiting with a timeout. Java does not expose a separate RUNNING state; RUNNABLE covers both ready-to-run and actually running. Once run() completes, the thread is TERMINATED, and you can only call start() once on a thread object.

What the lifecycle really means

Java gives each thread a Thread.State value so you can reason about what it is doing. The important mental model is that a thread is not always either “working” or “not working”; it can also be waiting for a lock, waiting for another thread, or sleeping for a timeout. A monitor is the lock attached to an object that synchronized uses.

Step-by-step: how a thread moves

1. Creation: When you write new Thread(...), the thread is NEW. It exists as an object, but the JVM has not asked the OS to schedule it yet.
2. Start: Calling start() tells the JVM to create a real thread and eventually invoke run(). The state becomes RUNNABLE.
3. Runnable means eligible: RUNNABLE is a broad bucket. In HotSpot JVMs, it covers both a thread that is actually executing and one that is ready but waiting its turn. Java does not show a separate RUNNING state.
4. Lock contention: If the thread tries to enter a synchronized block but another thread already owns that monitor, it becomes BLOCKED. It is waiting specifically for a monitor lock.
5. Waiting forever: If it calls wait(), join() with no timeout, or LockSupport.park(), it enters WAITING. This means it is waiting until some other action wakes it up.
6. Waiting with time: If it calls sleep(), wait(timeout), or join(timeout), it enters TIMED_WAITING. The thread will wake up after the timeout even if nobody notifies it.
7. Finish: When run() returns, the thread becomes TERMINATED. A terminated thread cannot be restarted.

How the common methods differ

Why this matters: sleep() pauses the current thread but keeps any locks it already holds, while wait() releases the lock and lets other threads enter the synchronized section. That one difference is the source of many bugs.

Performance and edge cases

• State transitions themselves are conceptually O(1), but the real cost comes from scheduling and context switches.
• A context switch can cost microseconds to milliseconds, so long lock holds and busy waiting can hurt latency.
• Thread.sleep(100) is not a precise timer; the actual wake-up time can be later because the scheduler decides when the thread runs again.
• start() can be called only once. Calling it twice throws IllegalThreadStateException.
• Interrupts do not magically stop a thread. They set the interrupted flag and may wake a thread from sleep(), wait(), or join() by throwing InterruptedException.

Memory hook: Think “New, Ready, Stuck, Waiting, Ticking, Terminated” — a thread is created, becomes eligible, may get stuck on a lock, may wait forever or for time, and finally ends.

Real-world story: checkout service under load

Imagine an e-commerce checkout service with a pool of worker threads handling payment and inventory updates. One worker grabs a database row lock inside a synchronized block or a database transaction, then does slow work inside that critical section. Other workers line up and become BLOCKED, while some request-processing threads wait on a queue or join on a background task and become WAITING or TIMED_WAITING.

What goes wrong when someone misunderstands the lifecycle? A developer uses sleep() instead of wait() while holding a lock, thinking it will “let others continue.” It does not release the monitor, so every other thread stays blocked behind that lock. In production, you see rising checkout latency, thread dumps full of BLOCKED workers, low CPU usage, and logs like “timeout waiting for payment confirmation” even though the machine is not overloaded.

The fix is usually to shorten the synchronized section, release the monitor before long waits, and use the right coordination tool for the job.

Follow-up & Tricky Questions:

Follow-up questions

• What is the difference between NEW and RUNNABLE?
  A thread is NEW after construction but before start(). After start(), it becomes RUNNABLE, meaning the JVM has asked the OS to schedule it.
• Why does Java not have a separate RUNNING state?
  Because the JVM only exposes the states it can reliably observe. A thread can be executing now or merely ready to execute, and both are grouped into RUNNABLE.
• What is the difference between BLOCKED and WAITING?
  BLOCKED means the thread is trying to enter a synchronized block but another thread owns the monitor. WAITING means the thread voluntarily waited, such as on join() or wait(), and needs another action to continue.
• What happens if you call start() twice?
  The second call throws IllegalThreadStateException. A thread object is one-shot; once it has started, it cannot be restarted after completion.
• How does interrupt() interact with lifecycle states?
  It sets the interrupted flag and may wake a thread blocked in sleep(), wait(), or join() by throwing InterruptedException. It does not forcefully kill the thread.

Tricky / gotcha questions

• Does sleep() release a synchronized lock?
  No. The thread keeps any locks it already owns, which is why sleep() inside a synchronized section often causes contention.
• Is a thread in WAITING always blocked on a lock?
  No. Waiting means it is paused until another thread signals or until the target thread finishes. Lock contention is specifically BLOCKED.
• Can you call run() directly instead of start()?
  Yes, but that does not create a new thread; it just runs the method on the current thread. The lifecycle question often includes this because it is a common mistake.

Common Mistakes:

• Thinking RUNNABLE means “currently running.” Correction: it means the thread is eligible to run; Java does not expose a separate running state.
• Using sleep() to wait for another thread. Correction: use wait(), join(), futures, or other coordination tools depending on the problem.
• Forgetting that wait() requires ownership of the monitor. Correction: you must call it inside a synchronized block on the same object, or you get IllegalMonitorStateException.
• Calling start() twice or calling run() by mistake. Correction: call start() exactly once to create a new thread.

Memory Hook: Picture a worker badge: New gets the badge, Runnable stands in line, Blocked is stuck at a locked door, Waiting sits by the phone, Timed Waiting sets a timer, and Terminated goes home.

Cheat Sheet:

• NEW = thread object created, not started.
• start() moves it to RUNNABLE.
• BLOCKED = waiting for a monitor lock.
• WAITING = waiting indefinitely, often on join() or wait().
• TIMED_WAITING = waiting with a timeout, often on sleep() or timed join().
• TERMINATED = run() finished, cannot restart.

Practice Tasks:

• Write a small program that prints the state of a thread before and after start().
• Modify the demo so that one thread uses wait()/notifyAll() instead of join().
• Break the code on purpose by calling start() twice, then catch and print the exception.