Fork/join and parallel streams question 102 of 180 mid
How does ForkJoinPool differ from a fixed thread pool?
- It is a fixed pool with a nicer API
- Correct: Per-worker deques with work stealing, and a
jointhat runs pending tasks instead of blocking - It creates a thread per task
- It is only for parallel streams
A fixed pool has one shared queue, and every worker contends on it. A fork/join pool gives each worker a deque it owns, pushing and popping its own end with no contention, and stealing from the other end of someone else's when it runs dry.
The other half is join. In a plain pool, waiting for a subtask blocks a worker and can starve the
pool. In fork/join, join first tries to execute other pending tasks on the current thread, so the
thread stays useful and recursive decomposition does not deadlock.
That design targets CPU-bound divide-and-conquer. For independent blocking tasks it brings nothing over a plain pool, and its assumptions actively hurt.
Quiz yourself on Fork/join and parallel streams Suggest a correction