forkjoinpool线程数应按任务类型选择：纯计算型用默认值（cpu核数-1），混合型可设为cpu核数×2；recursivetask自动合并返回值，recursiveaction无结果合并，适合副作用操作；阈值需权衡并行开销与cpu利用率，建议从array.length/(parallelism×4)起步实测；阻塞操作必须移出compute()或用managedblock()包装，否则导致线程饥饿。
ForkJoinPool 怎么选线程数才不拖慢任务
ForkJoinPool 默认并行度是 Runtime.getRuntime().availableProcessors() - 1（注意不是全部核数），这是为避免工作线程和后台 GC 线程争抢 CPU。如果你的任务大量阻塞（比如 IO），默认配置反而会让线程闲置、吞吐下降。
- 纯计算型任务：保持默认即可，改大可能引发上下文切换开销
- 混合型任务（含短 IO 或 sleep）：可显式构造
ForkJoinPool(int parallelism)，设为availableProcessors() * 2左右观察效果 - 全局替换默认池（不推荐）：用
ForkJoinPool.commonPool().shutdown()+ 自定义池接管，但会影响所有用commonPool()的第三方库
RecursiveTask 和 RecursiveAction 的核心区别在哪
区别不在“能不能返回值”，而在于框架如何调度和合并结果——RecursiveTask 的 invoke() 或 join() 会等待子任务完成并自动获取 compute() 返回值；RecursiveAction 的 compute() 返回 void，没有结果合并逻辑，适合副作用操作（如批量写文件、更新数组某段）。
- 误用
RecursiveAction去做需要累加的归并（如求和），就得自己维护共享变量，容易出竞态 - 用
RecursiveTask却忽略返回值或没在compute()里 return，会导致父任务拿到null或默认值，运行时可能 NPE - 子任务调用
fork()后，必须用join()获取结果（RecursiveTask）或确保执行完成（RecursiveAction），只fork()不join()是常见漏写点
任务拆分阈值（threshold）设多少才算合理
阈值不是越大越好，也不是越小越好。它本质是「串行执行 vs. 并行开销」的平衡点。拆太细，任务创建、队列入栈、线程唤醒的开销会盖过计算收益；拆太粗，并行度上不去，CPU 利用率低。
- 简单规则：对数组处理类任务，阈值常设为
array.length / (parallelism * 4)左右起步（例如 100 万元素、8 核机器，初试 3 万） - 用
System.nanoTime()对比不同阈值下总耗时，重点关注 5~10 次运行的中位数，避开 GC 毛刺干扰 - 避免用固定数字如
10或1000—— 这在小数据集上可能触发过度拆分，在大数据集上又形同单线程
常见阻塞操作为什么会让 ForkJoinPool 卡住
ForkJoinPool 的工作线程是**守护线程**，且默认不允许阻塞。一旦在 compute() 里调用 Thread.sleep()、Object.wait()、数据库查询、Socket 读写等，该线程就挂起，无法窃取其他任务，整个池可能因线程耗尽而停滞。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：把阻塞操作移出
compute()，改用CompletableFuture.supplyAsync(..., yourExecutor)配合自定义线程池处理 - 不得已要阻塞？先调用
ForkJoinPool.managedBlock(new ManagedBlocker() {...})告知框架“我要停一下”，否则可能触发RejectionException - 日志里看到
Attempt to invoke fork() from non-FJ thread或大量helpQuiesce()调用，基本就是阻塞导致线程饥饿了
public class SumTask extends RecursiveTask<Long> {
private final int[] array;
private final int lo, hi;
private static final int THRESHOLD = 10_000; // 实际应按数据量动态算
<pre class='brush:java;toolbar:false;'>SumTask(int[] array, int lo, int hi) {
this.array = array;
this.lo = lo;
this.hi = hi;
}
@Override
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(); // 异步提交左子任务
long rightResult = right.compute(); // 当前线程算右半边（避免额外线程开销）
long leftResult = left.join(); // 等待左半边结果
return leftResult + rightResult;
}}
ForkJoin 的难点不在 API 调用，而在判断「哪里该切」「切多细」「哪些操作根本不能放进去」——这些没法靠文档背出来，得结合数据规模、硬件特征和实际 profile 结果反复调。
