2

假设我有这样的代码：

class Foo {
    private final ExecutorService executor;

    public Foo(ExecutorService executor) {
        this.executor = executor;
    }

    public void doSomething() {
        executor.execute(() -> {/* Do important task */});
    }
}

如果不是传入ThreadPoolExecutor我使用的构造函数，我可以获得更好的性能吗ForkJoinPool？如果是，那么为什么我应该更喜欢在任何情况下使用它而不是ThreadPoolExecutor.

更新 1

我的问题是关于ForkJoinPool通过ExecutorServiceAPI 的使用，并且不假设使用ForkJoinPool特定 API 进行递归任务拆分。

4

2 回答 2

2

是的，如果你有递归的非阻塞任务，你可以。

这是最近小丑会议上 Cay S. Horstmann 的精彩解释。

于 2017-11-13T09:48:35.910 回答
1

如果使用newWorkStealingPool会有效

public static ExecutorService newWorkStealingPool()

创建一个工作窃取线程池，使用所有可用处理器作为其目标并行度级别。

您可以从此文档页面找到优势：

ForkJoinPool为来自非ForkJoinTask客户端的提交以及管理和监控操作提供了入口点。

ForkJoinPool与其他类型的ExecutorService的不同之处主要在于采用了工作窃取：池中的所有线程都尝试查找并执行提交到池和/或由其他活动任务创建的任务（如果不存在，则最终阻塞等待工作） .

当大多数任务产生其他子任务（大多数ForkJoinTasks也是如此）时，以及当许多小任务从外部客户端提交到池时，这可以实现高效处理。尤其是在构造函数中将 asyncMode设置为 true 时，ForkJoinPools也可能适用于从未加入的事件式任务。

于 2017-11-13T10:30:59.663 回答