[concurrency-interest] ForkJoinPool not designed for nested Java 8 streams.parallel().forEach( ... )

Doug Lea dl at cs.oswego.edu
Tue May 6 14:18:43 EDT 2014

On 05/06/2014 01:54 PM, √iktor Ҡlang wrote:
>     The current default is to only generate a new thread if saturated,
>     which is the most conservative possible policy. If we allowed a
>     bound on compensations, then everything could freeze up if past
>     some arbitrary limit, which seems even less popular than risking
>     OutOfMemoryError (and RejectedExecutionException) thrown by
>     attempted Thread construction. Especially since you can use
>     ForkJoinWorkerThreadFactories and/or SecurityManagers or to bound
>     the total number of Threads in a program, whether by FJ or elsewhere.
> Assuming that there are other threads in the system than the pool, it'd be
> perfectly fine to have all threads in the pool stalled when waiting for external
> threads to complete/signal progress, right?

This might hold in practice in some applications and frameworks,
but not in general: these other threads may be using FJ and blocking
on results.

> How can ForkJoinWorkerThreadFactory be used to cap the maximum number of threads
> without blowing something up?

Create a factory that hands out up to a maximum number of threads,
else null. So long as it provides at least as many threads as
the parallelism level, then nothing blows up when null is returned
thereafter. (You'd also need some bookkeeping in


More information about the Concurrency-interest mailing list