forkjoinpool 适合可递归分解的 cpu 密集型任务，如归并排序、树遍历、分治计算和并行聚合；不适合阻塞 i/o、强顺序依赖、频繁共享写入或超短耗时任务。
什么样的任务适合用 ForkJoinPool
ForkJoinPool 不是通用线程池，它专为「可递归分解的 CPU 密集型任务」设计。如果你的任务能自然切分成子任务，且子任务之间无强依赖、无需频繁同步或 I/O 等待，才值得考虑。
典型场景包括：归并排序、快速排序、树形结构遍历（如 JSON 解析树）、分治型数值计算（如矩阵乘法分块、蒙特卡洛积分）、大规模数组/集合的聚合操作（parallelStream() 底层就用它）。
- ✅ 适合：任务粒度适中（太小会增加调度开销，太大无法充分利用多核），总计算量明显大于同步/通信成本
- ❌ 不适合：含阻塞 I/O（如文件读写、HTTP 调用）、需严格顺序执行、共享状态频繁写入（未加锁易出错）、单次任务耗时极短（
- ⚠️ 注意：
ForkJoinPool.commonPool()是 JVM 共享的，被parallelStream()、CompletableFuture等共用，若某任务长期占用或抛出未捕获异常，可能拖慢其他模块
ForkJoinTask 的两种子类怎么选
你得在 RecursiveAction（无返回值）和 RecursiveTask<t></t>（有返回值）之间做选择，本质取决于「子任务结果是否需要向上合并」。
- 用
RecursiveTask：比如求一个大数组的 sum，每个子任务算一段，最后left.join() + right.join() - 用
RecursiveAction：比如对数组每个元素做相同变换（如平方），不汇总结果，只关心副作用完成 - 别手动调
fork()/join()顺序：先fork()子任务，再处理当前逻辑，最后join()—— 否则失去并行意义；常见错误是fork().join()连写，等于同步执行 -
compute()方法里避免抛出受检异常：它不声明throws Exception，必须用运行时异常包装，否则编译不过
为什么 commonPool() 的并行度经常不是你预期的
ForkJoinPool.commonPool() 默认并行度 = Runtime.getRuntime().availableProcessors() - 1（至少为 1），不是 CPU 核数，也不是你传的参数。
