ForkJoinTask

通过ForkJoinPool运行的任务的抽象基础类。 ForkJoinTask是一个类线程的实体，但是比标准的线程更轻量。 大量的任务和子任务可能存在于ForkJoinPool中的少量线程中，因为使用代价。 主ForkJoinTask被明确提交到ForkJoinPool后开始执行，或者 没有参与ForkJoin计算，开始于ForkJoinPool.commonPool（） 通过fork,invoke 或者相关方法。一旦启动，它通常会启动其它的子任务。就像类名说明的一样，许多成需使用ForkJoinTask值包含fork join 或者衍生方法 invokeAll。但是这个类提供一些其它方法提供一些高级用法和允许支持新的fork/join处理的旷职机制。

ForkJoinTask是轻量级的Future。ForkJoinTask的效率来自于一系列的限制（只有部分是静态强制性的），这些性质反映了他们作文计算任务的主要用途。计算任务计算纯函数，操作完全独立的对象，最基本的协调机制是fork，它安排异步计算，join知道润结果已经计算完成才开始执行。计算应该最好避免同步方法和阻塞，应该从join任务中最小化阻塞同步的部分，或者使用Phaser等同步器来协调fork/join 调度。再分任务也不应该执行阻塞I/O，应该访问完全与其它运行中的任务独立的变量。这些指导强制不能执行检查异常比如IOExcption的抛出。 但是计算仍然可以处理非减产异常，重新把这些异常抛给调用者。 这些异常可能包括RejectedExecutionException，因为内部资源超出，比如分配内部任务队列失败。像抛出正常异常抛出，润给你可能包含异常堆栈。

定义和使用阻塞的ForkJoinTask是可能的，但是考虑三个因素：1 如果其他任务依赖于一个可能阻塞在外部同步或者I/O的任务时Cpmletion of few. 事件形异步任务从不join。2 最小化资源的影响。任务应该小；理想的是只执行阻塞行为 3 除非使用ForkJoinPool.ManagedBlocker API，否则 可能阻塞的任务应该小于池的级别，池不能保证足够的线程确保执行或者好性能

等待完成并抽取结果的主要方法是join，但是还有几个变体， Future.get方法支持打断或者等待一段时间。 invoke语法上等于 fork join 但是经常在当前线程中执行。 这些犯法的安静模式不抽取结果和抛出异常，当一些列任务正在执行是可能会有用，需要延迟结果的处理或抛出异常知道所有计算完成。 invokeALl方法执行全部的不妨调用形式： fork许多任务 join所有这些任务。

最常用的使用， fork-join对从一个并行递归函数调用和返回。其他形式的递归调用，付息还应该最先执行。比如 a.for;b.fork();bjoin();a.join(); 比 a.join() 在b.join()更有效率。

<p>The execution status of tasks may be queried at several levels * of detail: {[@link](https://my.oschina.net/u/393) #isDone} is true if a task completed in any way * (including the case where a task was cancelled without executing); * {[@link](https://my.oschina.net/u/393) #isCompletedNormally} is true if a task completed without * cancellation or encountering an exception; {[@link](https://my.oschina.net/u/393) #isCancelled} is * true if the task was cancelled (in which case {[@link](https://my.oschina.net/u/393) #getException} * returns a {[@link](https://my.oschina.net/u/393) java.util.concurrent.CancellationException}); and * {@link #isCompletedAbnormally} is true if a task was either * cancelled or encountered an exception, in which case {@link * #getException} will return either the encountered exception or * {@link java.util.concurrent.CancellationException}. * * <p>The ForkJoinTask class is not usually directly subclassed. * Instead, you subclass one of the abstract classes that support a * particular style of fork/join processing, typically {@link * RecursiveAction} for most computations that do not return results, * {@link RecursiveTask} for those that do, and {@link * CountedCompleter} for those in which completed actions trigger * other actions. Normally, a concrete ForkJoinTask subclass declares * fields comprising its parameters, established in a constructor, and * then defines a {@code compute} method that somehow uses the control * methods supplied by this base class. * * <p>Method {@link #join} and its variants are appropriate for use * only when completion dependencies are acyclic; that is, the * parallel computation can be described as a directed acyclic graph * (DAG). Otherwise, executions may encounter a form of deadlock as * tasks cyclically wait for each other. However, this framework * supports other methods and techniques (for example the use of * {@link Phaser}, {@link #helpQuiesce}, and {@link #complete}) that * may be of use in constructing custom subclasses for problems that * are not statically structured as DAGs. To support such usages, a * ForkJoinTask may be atomically <em>tagged</em> with a {@code short} * value using {@link #setForkJoinTaskTag} or {@link * #compareAndSetForkJoinTaskTag} and checked using {@link * #getForkJoinTaskTag}. The ForkJoinTask implementation does not use * these {@code protected} methods or tags for any purpose, but they * may be of use in the construction of specialized subclasses. For * example, parallel graph traversals can use the supplied methods to * avoid revisiting nodes/tasks that have already been processed. * (Method names for tagging are bulky in part to encourage definition * of methods that reflect their usage patterns.) * * <p>Most base support methods are {@code final}, to prevent * overriding of implementations that are intrinsically tied to the * underlying lightweight task scheduling framework. Developers * creating new basic styles of fork/join processing should minimally * implement {@code protected} methods {@link #exec}, {@link * #setRawResult}, and {@link #getRawResult}, while also introducing * an abstract computational method that can be implemented in its * subclasses, possibly relying on other {@code protected} methods * provided by this class. * * <p>ForkJoinTasks should perform relatively small amounts of * computation. Large tasks should be split into smaller subtasks, * usually via recursive decomposition. As a very rough rule of thumb, * a task should perform more than 100 and less than 10000 basic * computational steps, and should avoid indefinite looping. If tasks * are too big, then parallelism cannot improve throughput. If too * small, then memory and internal task maintenance overhead may * overwhelm processing. * * <p>This class provides {@code adapt} methods for {@link Runnable} * and {@link Callable}, that may be of use when mixing execution of * {@code ForkJoinTasks} with other kinds of tasks. When all tasks are * of this form, consider using a pool constructed in <em>asyncMode</em>. * * <p>ForkJoinTasks are {@code Serializable}, which enables them to be * used in extensions such as remote execution frameworks. It is * sensible to serialize tasks only before or after, but not during, * execution. Serialization is not relied on during execution itself.

转载于:https://my.oschina.net/u/3702259/blog/2251633