Thread Pool: Sizing & Pitfalls

Thread pool deadlock happens when parent tasks submit children to the same bounded pool and block on child.get(), exhausting all workers so children can never execute.

Executors.newFixedThreadPool() is dangerous because its unbounded LinkedBlockingQueue can grow to exhaust the heap, and the rejection handler never fires because the queue never reports as full.

Size CPU-bound pools to cores plus one, IO-bound pools to cores times (1 + wait/compute), and always verify with load testing because formulas are starting points, not answers.

Choose fixed for steady bounded load, cached for short bursts, scheduled for timed/periodic jobs, and ForkJoinPool for CPU-bound recursion, but never use ForkJoinPool for blocking IO because its core-sized pool stalls when workers block.

newCachedThreadPool explodes on long tasks because it creates unbounded threads, and the ForkJoin common pool explodes on blocking IO because it spawns compensating threads to maintain parallelism; both are fixed by bounded pools with back-pressure.

One Spring Boot request costs a thread stack plus its object graph plus about twice the JSON payload, and you measure it with heap diffs, Actuator metrics, and AOP sampling.

Concurrency equals throughput times latency, memory equals concurrency times per-request footprint plus steady state, and the garbage collector must clear that allocation inside the latency budget.