BLOCKED vs WAITING Thread State
Fast recall
Quick revision
Core answer
BLOCKED means a thread is waiting to enter a synchronized region because another thread owns that monitor. WAITING means it is waiting indefinitely for another action—for example Object.wait(), Thread.join(), or LockSupport.park(). A notified thread must still reacquire the monitor before wait() can return.Nuanced understanding — many freshers confuse these two
Saying they're the same — 'just waiting'
Explain the mechanism: BLOCKED is passive, WAITING is cooperative/voluntary
Interview-ready guide
Interview answer
BLOCKED and WAITING both mean a thread is not executing, but the reason is different. A BLOCKED thread is trying to acquire an intrinsic monitor for a synchronized region. A WAITING thread has paused indefinitely until another action occurs. This difference tells you whether to inspect lock contention or coordination logic.
Suppose thread A is inside synchronized (lock). Thread B becomes BLOCKED if it tries to enter code guarded by the same monitor. Thread B did not call a waiting method and does not own the monitor. It can continue only after the monitor becomes available and the JVM grants it ownership.
WAITING can be caused by lock.wait(), worker.join(), or LockSupport.park(), but they do not resume in exactly the same way. wait() can end through notification, interruption, or a spurious wake-up; join() completes when the target thread terminates; and park() can be released with unpark(). Only Object.wait() releases the monitor on which it is called.
After notify() selects a thread waiting on that object, the notified thread still must reacquire the same monitor before wait() can return. It may therefore appear BLOCKED while the notifying thread keeps the lock. In a thread dump, many BLOCKED threads suggest monitor contention; long-lived WAITING threads require checking the exact wait operation and what should complete it.
BLOCKED vs WAITING Thread State
Direct Answer
BLOCKED means a thread is waiting to enter a synchronized region because another thread owns that monitor. WAITING means it is waiting indefinitely for another action—for example Object.wait(), Thread.join(), or LockSupport.park(). A notified thread must still reacquire the monitor before wait() can return.
Code Example
public class BlockedVsWaiting {
static final Object lock = new Object();
public static void main(String[] args) throws InterruptedException {
// Holder takes the lock, then wait() — releases lock and goes WAITING
Thread holder = new Thread(() -> {
synchronized (lock) {
try { lock.wait(); }
catch (InterruptedException e) { Thread.currentThread().interrupt(); }
}
});
// Contender just tries to enter the block — gets BLOCKED if lock is held
Thread contender = new Thread(() -> { synchronized (lock) { /* work */ } });
holder.start(); Thread.sleep(100);
contender.start(); Thread.sleep(100);
System.out.println("holder: " + holder.getState()); // WAITING
System.out.println("contender: " + contender.getState()); // BLOCKED
synchronized (lock) { lock.notify(); }
}
}
BLOCKED means stuck at the lock door; WAITING means the thread released the lock voluntarily and needs a notify().
Common Mistakes & Pitfalls
- Treating them as identical: Freshers say 'both are just waiting' and miss that BLOCKED is automatic while WAITING needs explicit wake-up calls.
- Not checking thread dumps correctly: Seeing BLOCKED and trying to fix it by adding wait/notify logic makes things worse — BLOCKED needs lock optimization, not coordination code.
- Forgetting the monitor relationship: WAITING always happens inside a synchronized block on a specific monitor object, while BLOCKED happens trying to enter one. You can't call wait() without holding the lock first.
Check your understanding
Answer these without looking back at the article.
- Can a BLOCKED thread be interrupted?
- What causes a WAITING thread to move back to RUNNABLE?
- How do you see thread states in a thread dump?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.