ForkJoinPool 的异步模式是什么意思？ Javadoc 提到它使队列(是每线程队列吗？)FIFO 而不是 LIFO。这在实践中意味着什么？

最佳答案

ForkJoinPool 中的每个工作线程都有自己的工作队列。 Async mode 关注每个工作人员执行从未从其工作队列中加入的 fork 任务的顺序。

ForkJoinPool 中的工作人员在异步模式下以 FIFO(先进先出)顺序处理此类任务。默认情况下，ForkJoinPool 以 LIFO(后进先出)顺序处理此类任务。

需要强调的是，异步模式设置仅涉及从未加入的 fork 任务。当使用 ForkJoinPool 来实现其最初设计的目的时，即递归 fork /join 任务分解，asyncMode 根本不起作用。只有当 worker 不参与实际的 fork/join 处理时，它才会执行异步任务，并且只有在那时才真正查询 asyncMode 标志。

这是一个演示两种不同异步模式设置之间差异的小程序:

import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicInteger;

/**
 * Demo of {@code ForkJoinPool} behaviour in async and non-async mode.
 */
public class ForkJoinAsyncMode {
    public static void main(String[] args) {
        // Set the asyncMode argument below to true or false as desired:
        ForkJoinPool pool = new ForkJoinPool(
                4, ForkJoinPool.defaultForkJoinWorkerThreadFactory, null, true);

        pool.invoke(new RecursiveRangeAction(0, 200));
        pool.awaitQuiescence(2L, TimeUnit.SECONDS);
    }

    /**
     * A {@code ForkJoinTask} that prints a range if the range is smaller than a
     * certain threshold; otherwise halves the range and proceeds recursively.
     * Every recursive invocation also forks off a task that is never joined.
     */
    private static class RecursiveRangeAction extends RecursiveAction {
        private static final AtomicInteger ASYNC_TASK_ID = new AtomicInteger();

        private final int start;
        private final int end;

        RecursiveRangeAction(int start, int end) {
            this.start = start;
            this.end = end;
        }

        @Override
        protected void compute() {
            if (end - start < 10) {
                System.out.format("%s range [%d-%d] done%n",
                        Thread.currentThread().getName(), start, end);
            } else {
                int mid = (start + end) >>> 1;
                int id = ASYNC_TASK_ID.incrementAndGet();

                System.out.format(
                        "%1$s [%2$d-%3$d] -< [%3$d-%4$d], fork async task %5$d%n",
                        Thread.currentThread().getName(), start, mid, end, id);

                // Fork off additional asynchronous task that is never joined.
                ForkJoinTask.adapt(() -> {
                    System.out.format("%s async task %d done%n",
                            Thread.currentThread().getName(), id);
                }).fork();

                invokeAll(new RecursiveRangeAction(start, mid),
                        new RecursiveRangeAction(mid, end));
            }
        }
    }
}

在非异步模式(ForkJoinPool 的默认模式)下，从未加入的 fork 任务按后进先出顺序执行。

当您在非异步模式下运行示例程序时，查看一个 worker 的输出，您可能会看到如下模式:

ForkJoinPool-1-worker-0 [175-187] -< [187-200], fork async task 10
ForkJoinPool-1-worker-0 [175-181] -< [181-187], fork async task 11
ForkJoinPool-1-worker-0 range [175-181] done
ForkJoinPool-1-worker-0 range [181-187] done
ForkJoinPool-1-worker-0 [187-193] -< [193-200], fork async task 12
ForkJoinPool-1-worker-0 range [187-193] done
ForkJoinPool-1-worker-0 range [193-200] done
ForkJoinPool-1-worker-0 async task 12 done
ForkJoinPool-1-worker-0 async task 11 done
ForkJoinPool-1-worker-0 async task 10 done

在这里，任务 10、11、12 被 fork ，并在工作人员开始执行它们后以相反的顺序执行。

另一方面，在异步模式中，再次查看一个 worker 的输出，模式更像是如下所示:

ForkJoinPool-1-worker-3 [150-175] -< [175-200], fork async task 8
ForkJoinPool-1-worker-3 [150-162] -< [162-175], fork async task 9
ForkJoinPool-1-worker-3 [150-156] -< [156-162], fork async task 10
ForkJoinPool-1-worker-3 range [150-156] done
ForkJoinPool-1-worker-3 range [156-162] done
ForkJoinPool-1-worker-3 [162-168] -< [168-175], fork async task 11
...
ForkJoinPool-1-worker-3 async task 8 done
ForkJoinPool-1-worker-3 async task 9 done
ForkJoinPool-1-worker-3 async task 10 done
ForkJoinPool-1-worker-3 async task 11 done

任务 8、9、10、11 被 fork ，然后按照提交的顺序执行。

什么时候使用哪种模式？ Whenever a ForkJoinPool thread pool is chosen to take advantage of its work-stealing properties rather than for recursive fork/join task processing, async mode is probably the more natural choice, as tasks get executed in the order they已提交。

异步事件驱动框架，如 CompletableFuture有时据说从异步模式中获益。例如，当构造一个复杂的 CompletableFuture 回调链时，异步模式下的自定义 ForkJoinPool 执行器可能比默认执行器的性能稍好。 (虽然我不能根据经验说话。)

关于java - 什么是 ForkJoinPool 异步模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5640046/