Executors and thread pools question 90 of 180 senior
What breaks when a pooled task submits another task to the same pool and waits for it?
- Nothing, the pool grows as needed
- Correct: Thread starvation deadlock: the waiting tasks occupy every thread, and the tasks they wait for can never be scheduled
- The task is rejected
- The pool creates a new thread automatically
With a pool of N threads, if N tasks each block on the result of a subtask they submitted to the same
pool, there is no thread left to run any subtask. Nothing is deadlocked in the lock sense, so a dump
shows no cycle, only every worker parked in Future.get. It is invisible under light load and appears
the moment concurrency reaches the pool size.
Three ways out: separate pools for the two layers, so the dependency crosses a boundary; a non-blocking
composition with CompletableFuture so nothing waits; or ForkJoinPool, whose join runs pending
tasks on the current thread (the reason invokeAll inside fork/join is safe).
The same hazard appears with nested parallel streams, which all share the common pool by default.
Quiz yourself on Executors and thread pools Suggest a correction