Why one can't submit an alternative thread pool to the streams API?

[Brian Goetz]

> Thanks Brian. I will make my attempt to ship a module that makes it look like the pool selection is part of the API (as much as it can). If that fails I will create an alternate implementation based on existing one and maintain that. I really believe the decision to use common pool that every parallel streams execution competes for behind the scenes across the app is a good idea. It sure looks good when you call it but no one can know what is happening in some other part of a given application. Maybe some other thread is waiting for IO on most of the common pool threads. Everything would hang in some (seemingly) unrelated part of code.


I really hope that’s not the advice you thought I was giving you.  In fact, that’s the opposite of the advice I was giving!  Don’t try to create and manage your own pools.  Don’t try to expose APIs that encourage your users to create and manage their own pools.  Use parallel streams for data parallelism, which automatically use the common pool. The common pool is sized to the number of cores; if you create more threads, then they just compete for the cores, and you’re paying for extra context switching and you will get less throughput — plus (much) more memory consumption, more configuration, and more complexity.  

The “I know what is happening” that you are seeking is an illusion.  Don’t be tempted by it.  99.9% of the time, you’re just going to make it worse.