Thread Starvation in Java
Fast recall
Quick revision
Core answer
Whether the candidate knows the three main concurrency problems: race conditions, deadlock, and starvation
Confusing starvation with deadlock — in starvation the thread could eventually run; in deadlock it never can
Give a concrete cause like always using notify instead of notifyAll when there are multiple waiters
Interview-ready guide
Interview answer
Starvation happens when a thread or task is able to run in principle but keeps losing access to the resource it needs while other work continues. It can wait for CPU time, a heavily contested lock, a worker in an overloaded pool, or a connection that other tasks repeatedly obtain first.
That differs from deadlock: deadlock has a dependency cycle that stops the involved threads, while starvation is unfair or unbounded delay without needing a cycle. For lock contention, new ReentrantLock(true) uses a fair acquisition policy and usually gives the longest-waiting contender preference. I would describe that as reducing starvation, not guaranteeing strict FIFO completion, because scheduling and tryLock() have separate behavior. I would also shorten critical sections and inspect queue-wait metrics rather than assume a fairness flag solves every resource bottleneck.
Thread Starvation in Java
Direct Answer
Starvation means a thread or task is ready to make progress but keeps being denied the CPU, a lock, a pool slot, or another resource because other work is repeatedly favored. Unlike deadlock, other threads continue to make progress. Fairer scheduling or lock policies can reduce starvation, but a fair lock is not a strict guarantee of operating-system scheduling order.
Common Mistakes & Pitfalls
- Confusing starvation with deadlock: in deadlock, threads can never proceed; in starvation, a thread could run but keeps getting deprioritized.
- Using
notify()instead ofnotifyAll(): the classic cause — freshers thinknotify()is more efficient, not realizing it can leave threads starving. - Assuming the JVM scheduler is fair: same-priority threads may not get equal time, so you need an fair
ReentrantLockto favor queued contenders, while remembering it is not a strict scheduler FIFO guarantee.
Check your understanding
Answer these without looking back at the article.
- What is a fair lock in Java?
- What is the difference between ReentrantLock(true) and synchronized?
- Can starvation cause performance problems without total failure?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.