A {@code ForkJoinPool} differs from other kinds of {@link java.util.concurrent.ExecutorService} mainly by virtue of employingwork-stealing: all threads in the pool attempt to find and execute tasks submitted to the pool and/or created by other active tasks (eventually blocking waiting for work if none exist). This enables efficient processing when most tasks spawn other subtasks (as do most {@code ForkJoinTask}s), as well as when many small tasks are submitted to the pool from external clients. Especially when setting asyncMode to true in constructors, {@code ForkJoinPool}s may also be appropriate for use with event-style tasks that are never joined.
A static {@link #commonPool()} is available and appropriate formost applications. The common pool is used by any ForkJoinTask that is not explicitly submitted to a specified pool. Using the common pool normally reduces resource usage (its threads are slowly reclaimed during periods of non-use, and reinstated upon subsequent use).
For applications that require separate or custom pools, a {@code ForkJoinPool} may be constructed with a given target parallelismlevel; by default, equal to the number of available processors. The pool attempts to maintain enough active (or available) threads by dynamically adding, suspending, or resuming internal worker threads, even if some tasks are stalled waiting to join others. However, no such adjustments are guaranteed in the face of blocked I/O or other unmanaged synchronization. The nested {@link io.netty.util.internal.chmv8.ForkJoinPool.ManagedBlocker} interface enables extension of the kinds ofsynchronization accommodated.
In addition to execution and lifecycle control methods, this class provides status check methods (for example {@link #getStealCount}) that are intended to aid in developing, tuning, and monitoring fork/join applications. Also, method {@link #toString} returns indications of pool state in aconvenient form for informal monitoring.
As is the case with other ExecutorServices, there are three main task execution methods summarized in the following table. These are designed to be used primarily by clients not already engaged in fork/join computations in the current pool. The main forms of these methods accept instances of {@code ForkJoinTask}, but overloaded forms also allow mixed execution of plain {@code Runnable}- or {@code Callable}- based activities as well. However, tasks that are already executing in a pool should normally instead use the within-computation forms listed in the table unless using async event-style tasks that are not usually joined, in which case there is little difference among choice of methods.
| Call from non-fork/join clients | Call from within fork/join computations | |
| Arrange async execution | {@link #execute(ForkJoinTask)} | {@link ForkJoinTask#fork} |
| Await and obtain result | {@link #invoke(ForkJoinTask)} | {@link ForkJoinTask#invoke} |
| Arrange exec and obtain Future | {@link #submit(ForkJoinTask)} | {@link ForkJoinTask#fork} (ForkJoinTasks are Futures) |
The common pool is by default constructed with default parameters, but these may be controlled by setting three {@link System#getProperty system properties} with prefix {@code java.util.concurrent.ForkJoinPool.common}: {@code parallelism} --an integer greater than zero, {@code threadFactory} -- the classname of a {@link io.netty.util.internal.chmv8.ForkJoinPool.ForkJoinWorkerThreadFactory}, and {@code exceptionHandler} -- the class name of a {@link java.lang.Thread.UncaughtExceptionHandler Thread.UncaughtExceptionHandler}. Upon any error in establishing these settings, default parameters are used.
Implementation notes: This implementation restricts the maximum number of running threads to 32767. Attempts to create pools with greater than the maximum number result in {@code IllegalArgumentException}.
This implementation rejects submitted tasks (that is, by throwing {@link java.util.concurrent.RejectedExecutionException}) only when the pool is shut down or internal resources have been exhausted. @since 1.7 @author Doug Lea
A {@code ForkJoinPool} differs from other kinds of {@link ExecutorService} mainly by virtue of employingwork-stealing: all threads in the pool attempt to find and execute tasks submitted to the pool and/or created by other active tasks (eventually blocking waiting for work if none exist). This enables efficient processing when most tasks spawn other subtasks (as do most {@code ForkJoinTask}s), as well as when many small tasks are submitted to the pool from external clients. Especially when setting asyncMode to true in constructors, {@code ForkJoinPool}s may also be appropriate for use with event-style tasks that are never joined.
A static {@link #commonPool()} is available and appropriate formost applications. The common pool is used by any ForkJoinTask that is not explicitly submitted to a specified pool. Using the common pool normally reduces resource usage (its threads are slowly reclaimed during periods of non-use, and reinstated upon subsequent use).
For applications that require separate or custom pools, a {@code ForkJoinPool} may be constructed with a given target parallelismlevel; by default, equal to the number of available processors. The pool attempts to maintain enough active (or available) threads by dynamically adding, suspending, or resuming internal worker threads, even if some tasks are stalled waiting to join others. However, no such adjustments are guaranteed in the face of blocked I/O or other unmanaged synchronization. The nested {@link ManagedBlocker} interface enables extension of the kinds ofsynchronization accommodated.
In addition to execution and lifecycle control methods, this class provides status check methods (for example {@link #getStealCount}) that are intended to aid in developing, tuning, and monitoring fork/join applications. Also, method {@link #toString} returns indications of pool state in aconvenient form for informal monitoring.
As is the case with other ExecutorServices, there are three main task execution methods summarized in the following table. These are designed to be used primarily by clients not already engaged in fork/join computations in the current pool. The main forms of these methods accept instances of {@code ForkJoinTask}, but overloaded forms also allow mixed execution of plain {@code Runnable}- or {@code Callable}- based activities as well. However, tasks that are already executing in a pool should normally instead use the within-computation forms listed in the table unless using async event-style tasks that are not usually joined, in which case there is little difference among choice of methods.
| Call from non-fork/join clients | Call from within fork/join computations | |
| Arrange async execution | {@link #execute(ForkJoinTask)} | {@link ForkJoinTask#fork} |
| Await and obtain result | {@link #invoke(ForkJoinTask)} | {@link ForkJoinTask#invoke} |
| Arrange exec and obtain Future | {@link #submit(ForkJoinTask)} | {@link ForkJoinTask#fork} (ForkJoinTasks are Futures) |
The common pool is by default constructed with default parameters, but these may be controlled by setting three {@linkplain System#getProperty system properties}:
Implementation notes: This implementation restricts the maximum number of running threads to 32767. Attempts to create pools with greater than the maximum number result in {@code IllegalArgumentException}.
This implementation rejects submitted tasks (that is, by throwing {@link RejectedExecutionException}) only when the pool is shut down or internal resources have been exhausted. @since 1.7 @author Doug Lea
A {@code ForkJoinPool} differs from other kinds of {@link ExecutorService} mainly by virtue of employingwork-stealing: all threads in the pool attempt to find and execute tasks submitted to the pool and/or created by other active tasks (eventually blocking waiting for work if none exist). This enables efficient processing when most tasks spawn other subtasks (as do most {@code ForkJoinTask}s), as well as when many small tasks are submitted to the pool from external clients. Especially when setting asyncMode to true in constructors, {@code ForkJoinPool}s may also be appropriate for use with event-style tasks that are never joined.
A {@code ForkJoinPool} is constructed with a given targetparallelism level; by default, equal to the number of available processors. The pool attempts to maintain enough active (or available) threads by dynamically adding, suspending, or resuming internal worker threads, even if some tasks are stalled waiting to join others. However, no such adjustments are guaranteed in the face of blocked IO or other unmanaged synchronization. The nested {@link ManagedBlocker} interface enables extension of the kinds ofsynchronization accommodated.
In addition to execution and lifecycle control methods, this class provides status check methods (for example {@link #getStealCount}) that are intended to aid in developing, tuning, and monitoring fork/join applications. Also, method {@link #toString} returns indications of pool state in aconvenient form for informal monitoring.
As is the case with other ExecutorServices, there are three main task execution methods summarized in the following table. These are designed to be used primarily by clients not already engaged in fork/join computations in the current pool. The main forms of these methods accept instances of {@code ForkJoinTask}, but overloaded forms also allow mixed execution of plain {@code Runnable}- or {@code Callable}- based activities as well. However, tasks that are already executing in a pool should normally instead use the within-computation forms listed in the table unless using async event-style tasks that are not usually joined, in which case there is little difference among choice of methods.
| Call from non-fork/join clients | Call from within fork/join computations | |
| Arrange async execution | {@link #execute(ForkJoinTask)} | {@link ForkJoinTask#fork} |
| Await and obtain result | {@link #invoke(ForkJoinTask)} | {@link ForkJoinTask#invoke} |
| Arrange exec and obtain Future | {@link #submit(ForkJoinTask)} | {@link ForkJoinTask#fork} (ForkJoinTasks are Futures) |
Sample Usage. Normally a single {@code ForkJoinPool} isused for all parallel task execution in a program or subsystem. Otherwise, use would not usually outweigh the construction and bookkeeping overhead of creating a large set of threads. For example, a common pool could be used for the {@code SortTasks}illustrated in {@link RecursiveAction}. Because {@code ForkJoinPool} uses threads in {@linkplain java.lang.Thread#isDaemon daemon} mode, there is typically no need to explicitly {@link #shutdown} such a pool upon program exit.
{@code static final ForkJoinPool mainPool = new ForkJoinPool(); ...}public void sort(long[] array) mainPool.invoke(new SortTask(array, 0, array.length)); }} Implementation notes: This implementation restricts the maximum number of running threads to 32767. Attempts to create pools with greater than the maximum number result in {@code IllegalArgumentException}.
This implementation rejects submitted tasks (that is, by throwing {@link RejectedExecutionException}) only when the pool is shut down or internal resources have been exhausted. @since 1.7 @author Doug Lea
| |