Concurrency in real systems question 133 of 180 senior
What breaks when you use a parallel stream inside a web request?
- Nothing, it makes the request faster
- Correct: Every request shares one common pool sized to the cores, so requests interfere with each other and any blocking call inside starves the whole JVM
- The stream runs sequentially inside a servlet
- It breaks the transaction only
A parallel stream uses ForkJoinPool.commonPool(), which has availableProcessors() - 1 threads for
the entire JVM. Under one request it looks fast. Under a hundred concurrent requests, they all compete
for those few threads, and the latency you measured in isolation disappears.
Put a blocking call in the stream and it is worse: the common pool is now held by I/O waits, and every other parallel operation in the process, including ones inside libraries, stalls behind it. Add the transaction and context problems from the earlier questions, since the work is now on pool threads.
When the collection is large and the work is genuinely CPU-bound, run it in an executor you own and size deliberately. When it is not, a sequential stream inside the request thread is both faster and easier to reason about.
Quiz yourself on Concurrency in real systems Suggest a correction