What is thread starvation?

Thread starvation is when a thread is perpetually denied the resources it needs to make progress – usually CPU time or a lock – because other threads monopolize them. It happens when some threads hold locks far too long, when higher-priority threads crowd out lower-priority ones, or when a thread pool is too small so tasks queue up and effectively never run in time. You diagnose it from a thread dump that shows many threads stuck in WAITING or BLOCKED states while only a few threads hold resources or run.

What causes thread starvation?

Starvation comes from a few distinct causes. The first is long-held locks: if one thread holds a lock while doing slow work, like a network call or a big computation, every other thread that needs that lock is blocked and starves. The second cause is an undersized thread pool: if you have a pool of a few threads but hundreds of tasks that each block on I/O, all threads get stuck waiting and new tasks queue indefinitely. The third cause is thread priority abuse: if higher-priority threads dominate the CPU, lower-priority threads never get scheduled.

How does starvation appear in banking code?

package com.bank.service;

import java.math.BigDecimal;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class PaymentService {
    // BAD: single pool for both fast and slow operations
    private final ExecutorService pool = Executors.newFixedThreadPool(4);

    public void processTransfer(String fromId, String toId, BigDecimal amount) {
        pool.submit(() -> {
            // SLOW: calls external bank API, takes 5 seconds
            externalBankApi.send(fromId, toId, amount);
        });
    }

    public void checkBalance(String accountId) {
        pool.submit(() -> {
            // FAST: local database lookup, takes 10ms
            return accountRepo.getBalance(accountId);
            // But this task waits in the queue behind slow transfers!
        });
    }
}

All four pool threads are stuck on slow external API calls. The quick balance checks are queued behind them and effectively starved of a thread to run on. Response times for balance checks grow from 10 ms to several seconds.

Thread-pool deadlock by starvation

A particularly nasty variant is when tasks in a bounded pool submit sub-tasks to the same pool and then wait for them. All threads can end up waiting for sub-tasks that can never start because no thread is free.

// DANGEROUS: pooled task submits to the same pool and waits
pool.submit(() -> {
    Future<?> subtask = pool.submit(() -> computeInterest(accountId));
    subtask.get();  // blocks this thread waiting for a thread from the same pool!
});
// If all threads do this, every thread is blocked waiting for work
// that can never start. The pool makes no progress.

The fix is to never block a pooled thread on work that must run in the same pool, or to use separate pools.

How do you diagnose starvation?

Take a thread dump and look at the distribution of thread states. If you see many threads in WAITING (parked, waiting on a condition or a pool's work queue) or BLOCKED (waiting for a lock) while only one or a few threads are RUNNABLE holding resources, that pattern points to starvation.

jstack <pid> | grep -c "WAITING"   # count waiting threads
jstack <pid> | grep -c "BLOCKED"   # count blocked threads
jstack <pid> | grep -c "RUNNABLE"  # count active threads
# Many WAITING/BLOCKED + few RUNNABLE = starvation

For a pool, watch the active worker count against the queue depth on a dashboard. A growing queue with all workers blocked is the signature.

How do you fix starvation?

Fix 1: Separate pools for fast and slow work (bulkhead pattern)

package com.bank.service;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class PaymentServiceFixed {
    // Separate pools: slow work cannot starve fast work
    private final ExecutorService transferPool = Executors.newFixedThreadPool(8);
    private final ExecutorService balancePool = Executors.newFixedThreadPool(4);

    public void processTransfer(/* ... */) {
        transferPool.submit(() -> externalBankApi.send(/* ... */));
    }

    public void checkBalance(String accountId) {
        balancePool.submit(() -> accountRepo.getBalance(accountId));
    }
}

Fix 2: Proper pool sizing using Little's Law: pool size = throughput x latency. If you handle 100 requests/sec and each takes 200 ms, you need at least 20 threads.

Fix 3: Fair locks – new ReentrantLock(true) grants access in arrival order, preventing a thread from being skipped indefinitely. The trade-off is lower throughput because the scheduler cannot optimize thread selection.

What should a senior engineer know?

• Distinguish starvation from deadlock and livelock. In deadlock, threads are blocked on each other in a cycle forever. In starvation, threads could run if they got a turn, but they keep being passed over.
• Virtual threads (Java 21+) reduce starvation risk for I/O-bound workloads because blocking a virtual thread does not block a platform thread.
• In banking at National Bank of India, separating fast and slow work into different pools is the single most effective habit Rajesh uses for preventing starvation in the payment service.