All 15 Concurrency & Threads questions
More in Concurrency & Threads
What is the synchronized keyword, and how does it use Java's intrinsic (monitor) locks to prevent race conditions on shared mutable state? What is the ExecutorService framework, and why is it generally preferred over manually creating and managing individual Thread objects? What causes a deadlock in multithreaded Java code, and what is the classic "lock ordering" strategy for preventing it? What are the atomic classes in java.util.concurrent.atomic (AtomicInteger, AtomicLong, AtomicReference), and how do they achieve thread-safe operations without traditional locking? What is the difference between wait()/notify()/notifyAll() (Object's intrinsic monitor methods) and the newer java.util.concurrent tools, and why are the older methods considered error-prone? What is a race condition, and how does it differ conceptually from a deadlock as two distinct categories of concurrency bugs? How does java.util.concurrent's ReentrantLock differ from the synchronized keyword, and what additional capabilities does it provide (tryLock, fairness, interruptible locking)? How do CompletableFuture's composition methods (thenApply, thenCompose, thenCombine) enable building asynchronous pipelines, and what's the difference between thenApply and thenCompose? How does the Java Memory Model's happens-before relationship formally define when changes made by one thread are guaranteed to be visible to another thread, and what role does the volatile keyword play? How would you use CountDownLatch, CyclicBarrier, and Semaphore for different thread coordination scenarios, and what distinguishes their use cases?
Advertisement
Java › Concurrency & Threads

What is thread starvation, and how can thread priority misuse or unfair lock scheduling contribute to it?

Intermediate

Answer

Thread starvation occurs when a thread is perpetually denied access to a resource it needs to make progress, typically because other threads are repeatedly favored for scheduling or lock acquisition -- setting overly aggressive thread priorities (Thread.setPriority()) can starve lower-priority threads on some JVM/OS combinations (though thread priority is only a hint and behaves inconsistently across platforms, making it generally an unreliable and discouraged tool), and a non-fair lock (the default for both synchronized and ReentrantLock unless fairness is explicitly requested) can theoretically let some threads repeatedly "jump the queue" ahead of a thread that's been waiting longest, though non-fair locks are still generally preferred for their better overall throughput despite this theoretical starvation risk in adversarial scenarios.
// Non-fair (default) ReentrantLock -- higher throughput, but theoretically allows starvation
ReentrantLock lock = new ReentrantLock();  // fair = false by default

// Fair lock -- reduces (but doesn't eliminate) starvation risk, at the cost of some throughput
ReentrantLock fairLock = new ReentrantLock(true);
Real-world example A background task perpetually failing to acquire a heavily-contended lock under sustained load from many higher-frequency competing threads is diagnosed as a starvation issue, addressed by switching that specific lock to fair mode, trading a modest amount of overall throughput for a guarantee that no single thread gets perpetually starved.

Common follow-ups: Why is Thread priority considered an unreliable mechanism across different JVM/OS combinations?;What's the throughput cost of enabling fairness on a ReentrantLock, and when is that trade-off worthwhile?

Diagnostics & Performance;Rate Limiting
All 15 Concurrency & Threads questions