[concurrency-interest] What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool?

Doug Lea dl at cs.oswego.edu
Mon Feb 20 14:07:18 EST 2012

(Slowly catching up with mail.)

On 02/16/12 07:06, Mohan Radhakrishnan wrote:
> Does ... mean that now I can submit independent tasks to the FJ framework
> without the need for a task and subtask graph and still get the benefits of
> work stealing ?

You get *some* of the benefits of work-stealing -- mainly decentralized
queuing and much better scalability.

The main tradeoff compared to ThreadPoolExecutor is that you have less
control (for example no direct access to submission queues) and essentially
no configuration methods. (Although most people seem to agree that
lack of such methods and options is a feature not a bug. In part because
it simplifies our ability to improve internal implementations over time
in ways that we cannot do with TPE because it reveals so much of its
internal workings.)

The other tradeoff is that FJP generally uses more CPU cycles
and memory than TPE.

All other things being equal, as a rough rule of thumb, if you are
running with 4 or fewer processors/cores, you probably won't see any
advantage to using FJP vs TPE as an "plain" ExecutorService. And
for a singleton (size one) pool, TPE is clearly better.
On larger platforms, FJP can be almost arbitrarily faster.


More information about the Concurrency-interest mailing list