recursivetask 是 forkjoinpool 中唯一支持有返回值递归计算的正统方式，因其专为 fork/join 模型设计，提供 work-stealing、自动结果合并、栈深度控制与异常传播；runnable 无返回值，callable 不参与 fork/join 协作链路，均无法实现递归任务拆分与归并。
RecursiveTask 是 ForkJoinPool 里做有返回值递归计算的唯一正统方式，不是“一种选择”，而是“必须用它”才能让 fork/join 模型正确归并结果。
为什么不能用 Runnable 或 Callable 直接丢进 ForkJoinPool？
ForkJoinPool 的核心是 work-stealing + 结果自动合并，而 Runnable 没返回值、Callable 虽有返回值但不参与 fork/join 的任务链路——它会被当作普通线程池任务执行，完全绕过 ForkJoinTask 的 fork()/join() 协作机制，更不会触发子任务结果自动累加。
-
ForkJoinPool.invoke()只接受ForkJoinTask子类，Callable包一层AdaptedCallable也只支持单次执行，无法递归拆分 - 手动 new Thread() 或用
Executors线程池模拟递归，会丢失任务窃取、栈深度控制、异常传播等关键能力 - 返回类型必须是泛型
V，且子类需重写compute()，否则编译不通过
compute() 里 fork() 和 join() 的调用顺序很关键
典型错误是先 join() 再 fork()，或者漏掉 join() 导致结果没收集。正确模式永远是：可拆分 → fork() 子任务 → join() 获取结果 → 合并；不可拆分 → 直接计算并 return。
- 必须用
fork()启动子任务，不能直接new SubTask().compute()，否则变成同步调用，失去并行意义 -
join()是阻塞等待+获取返回值，如果子任务还没完成，当前线程会去偷其他队列的任务，这是 work-stealing 的关键 - 两个子任务要分别
fork()再分别join()，不能fork(a); fork(b); return a.join() + b.join();—— 这样a和b是变量名，不是任务实例，会编译报错
正确写法示例：
protected Long compute() {
if (end - start <= THRESHOLD) {
return computeDirectly();
}
int mid = (start + end) / 2;
SumTask left = new SumTask(arr, start, mid);
SumTask right = new SumTask(arr, mid, end);
left.fork(); // 异步提交左任务
long rightResult = right.compute(); // 右任务直接算（避免再 fork 增加开销）
long leftResult = left.join(); // 等左任务结果
return leftResult + rightResult;
}阈值（threshold）设太小或太大都会拖慢性能
阈值决定“何时停止递归拆分”，它不是业务逻辑分界点，而是并发调度的成本平衡点。设错会导致大量短命任务（GC 压力大）或并行度不足（CPU 空转）。
- 对数组求和这类简单操作，
THRESHOLD通常设为 1000–10000；计算密集型（如矩阵乘）可更大；IO 或锁竞争任务则应禁用 fork/join - 不要用固定数字硬编码，建议根据
ForkJoinPool.getCommonPoolParallelism()动态估算，比如arr.length / parallelism - 注意：JDK 10+ 对小任务做了优化，但
threshold = 1仍会导致任务数爆炸，实测常见性能拐点在 500 左右
异常处理容易被忽略：compute() 抛异常 ≠ 外层 get() 抛异常
RecursiveTask 内部抛出的异常不会立即传播，而是被封装进 ForkJoinTask 的状态，直到调用 join() 或 invoke() 才触发。这点和普通方法调用完全不同。
- 子任务里
throw new RuntimeException("boom")，父任务join()时才会抛出ExecutionException，且getCause()才是原始异常 - 如果父任务没调用
join()（比如只fork()了但忘了等），异常会静默丢失 - 多个子任务都异常时，只抛出第一个被
join()到的异常，其余被吞掉——必须每个join()都套 try-catch 才能捕获全部
所以别依赖顶层 try-catch，要在每个 join() 后检查异常，或者统一用 invokeAll(tasks) + 遍历 isCompletedAbnormally()。
真正难的不是写对 compute()，而是判断“这个任务到底适不适合 fork/join”——数据局部性差、分支逻辑复杂、或结果依赖外部状态时，RecursiveTask 反而比单线程还慢。
