为什么常见的 ForkJoinPool 不尝试使用所有内核？答案

【问题标题】：Why doesn't the common ForkJoinPool try to use all cores?为什么常见的 ForkJoinPool 不尝试使用所有内核？
【发布时间】：2018-09-18 10:48:08
【问题描述】：

我明白为什么线程池大小与 CPU 内核数量有关，但为什么 ForkJoinThread 的设计者默认使用 # of cpu cores - 1 线程？为什么是-1？

如果我正在构建自己的ForkJoinPool（不使用公共实例），并且main 线程被阻塞在池中等待它返回一些结果，那么我有什么理由想要分配少于Runtime.getRuntime().availableProcessors() 线程？

更新：请解释你为什么投反对票。否则，我无法改进问题。

【问题讨论】：

JVM 通常会保留一些核心来进行垃圾收集。它高度依赖于您正在运行的架构，以及选择了哪种 GC 实现。 docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/…
@AndrewRueckert 与其对评论投反对票，不如将其发布为答案？这是一个合理的解释。
我没有对你投反对票，但我认为我的回答不够可靠，不足以成为“答案”。反正我错了！ ://

标签： java threadpool fork-join

【解决方案1】：

Oracle JDK implementation 中有评论。它指出

 * When external threads submit to the common pool, they can
 * perform subtask processing (see externalHelpComplete and
 * related methods) upon joins.  This caller-helps policy makes it
 * sensible to set common pool parallelism level to one (or more)
 * less than the total number of available cores, or even zero for
 * pure caller-runs.

换句话说，当外部（不是 FJP 线程的一部分）（可以）帮助执行任务时，额外的线程并不总是有益的。

【讨论】：

很好的发现。谢谢！

【解决方案2】：

这是有道理的。主线程始终需要一个线程，一次运行的最大线程数是内核总数。因此，默认并行度为# of cpu cores - 1。

【讨论】：