ForkJoinPool适用于天然可分的递归任务（如数组求和、树遍历），依赖工作窃取提升效率；应优先使用commonPool()，合理设置拆分阈值，避免用于非递归或阻塞型任务。
用 ForkJoinPool 拆分递归型任务最直接
当任务天然可分（比如数组求和、树遍历、归并排序），ForkJoinPool 是 Java 标准库中专为“分而治之”设计的线程池。它不是靠增加线程数硬扛，而是靠工作窃取（work-stealing）让空闲线程主动拿走其他线程的子任务，减少线程阻塞。
关键点：
-
ForkJoinTask的子类（如RecursiveTask<V>）必须重写compute()，并在其中判断是否达到阈值——太小就直接算，太大就fork()拆分 - 不要手动创建
ForkJoinPool实例；优先用公共池：ForkJoinPool.commonPool()，避免资源浪费 - 拆分阈值不是越小越好。实测中，对 100 万整数求和，阈值设为 10000 左右比 100 快 2–3 倍；过细拆分会导致任务调度开销反超计算收益
class SumTask extends RecursiveTask<Long> {
final long[] array;
final int lo, hi;
static final int THRESHOLD = 10000;
<pre class='brush:java;toolbar:false;'>SumTask(long[] array, int lo, int hi) {
this.array = array; this.lo = lo; this.hi = hi;
}
protected Long compute() {
if (hi - lo <= THRESHOLD) {
long sum = 0;
for (int i = lo; i < hi; i++) sum += array[i];
return sum;
}
int mid = (lo + hi) >> 1;
SumTask left = new SumTask(array, lo, mid);
SumTask right = new SumTask(array, mid, hi);
left.fork(); // 异步提交左子任务
return right.compute() + left.join(); // 当前线程算右子任务，再等左结果
}}
非递归任务别硬套 ForkJoinPool
如果任务之间无依赖、不可再分（比如处理 1000 个独立 HTTP 请求、解析 1000 个 JSON 文件），强行用 ForkJoinTask 反而增加封装成本和调度负担。这时更合适的是 CompletableFuture 配合普通线程池。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：
- 用
RecursiveAction包一层循环，每个元素都fork()—— 这等于把串行逻辑强行“伪并行”，没有真正拆分计算逻辑，还引入了 fork/join 开销 - 在
compute()中调用阻塞 I/O（如Thread.sleep()、数据库查询）——ForkJoinPool的工作线程不是为阻塞设计的，会拖垮整个池
正确做法是：用 Executors.newFixedThreadPool(n) 或 newCachedThreadPool()，再用 CompletableFuture.supplyAsync(() -> {...}, pool) 提交独立任务，最后 CompletableFuture.allOf() 等待全部完成。
parallelStream() 看似简单，但线程池不可控
list.parallelStream().map(...).reduce(...) 内部确实用了 ForkJoinPool.commonPool()，适合 CPU 密集型、无状态的简单转换。但它隐藏了所有调度细节，导致两个实际问题：
- 如果你的应用里已有其他模块也在用
commonPool（比如某个第三方库的异步日志），它们会竞争同一批线程，一个慢任务可能卡住所有并行流 -
commonPool默认线程数 = CPU 核心数 − 1（JDK 9+），无法按业务需求调整；比如你有 4 核机器，但想跑 8 个并发 HTTP 请求，parallelStream()会严重受限 - 无法捕获子任务抛出的异常——异常会被包装成
ForkJoinTask$RuntimeException，堆栈不直观
替代方案：自己构造 ForkJoinPool 实例（指定 parallelism 参数），再用 stream().parallel().forEach(...) 并指定 ForkJoinPool 的 submit() 方法执行，但更推荐回归到显式线程池 + CompletableFuture 组合，控制力更强。
拆分边界必须明确，否则反而降低效率
并行效率损失往往不出现在计算本身，而出现在拆分与合并阶段。比如：
- 对
ArrayList按索引拆分是 O(1)，但对LinkedList拆分需要遍历，拆一次就 O(n)，得不偿失 - 合并结果时若用同步容器（如
Collections.synchronizedList()）或频繁加锁，吞吐量会断崖下跌；应优先用无锁结构（如ConcurrentHashMap、AtomicIntegerArray）或让每个子任务返回局部结果再统一归约 - 任务粒度不均会导致负载不均衡。例如按固定大小切分文件行数，但每行长度差异极大（有的 1KB，有的 1MB），实际耗时差异可达百倍——这时需按字节偏移而非行数切分，或预扫描估算权重
真正影响并行效率的，从来不是“能不能并行”，而是“拆得是否干净、合得是否轻量、边界是否无共享”。多数性能问题，根子都在拆分逻辑没贴合数据特征。
