recursivetask与recursiveaction的核心区别在于是否返回结果：recursivetask用于有返回值的任务（如归并排序需返回子数组），recursiveaction用于无返回值的副作用操作；误用会导致编译失败或合并逻辑断裂。
RecursiveTask 与 RecursiveAction 的核心区别在哪
关键看是否需要返回结果：RecursiveTask 用于有返回值的并行任务（比如归并排序中每个子任务要返回已排序的子数组），RecursiveAction 用于无返回值的副作用操作（如仅对原数组某段做原地排序，不产生新数组）。归并排序天然需要合并两个有序子数组，必须组合子结果，所以优先选 RecursiveTask<int></int>，而不是 RecursiveAction。
用错类型会导致编译失败或运行时逻辑断裂——比如误用 RecursiveAction 后调用 invoke() 得到 void，无法参与合并步骤。
如何切分数组才不会触发栈溢出或线程饥饿
默认的 ForkJoinPool 使用 CPU 核心数作为并行度，但归并排序的递归深度与数据量对数相关，真正危险的是「切分粒度过小」：每层都 fork 新任务，即使数组只剩 2 个元素也提交任务，造成大量细粒度任务堆积，吞没 fork-join 线程队列。
- 设置阈值（threshold），例如
if (end - start 时改用 <code>Arrays.sort(arr, start, end)做插入排序，不再 fork - 避免每次 new 一个新子数组；对大数组应传入原数组 + 索引范围，在
compute()中复用内存，减少 GC 压力 - 不要在
compute()中直接调用fork()两次再join()；应先fork()左子任务，再同步计算右子任务，最后join()左结果——这样节省一次上下文切换
merge() 步骤为什么必须在 compute() 内完成，不能交给另一个 ForkJoinTask
归并排序的合并操作本身是 O(n) 时间、需顺序访问左右两个子数组，不具备可进一步有意义并行化的结构。如果为 merge() 单独封装成 RecursiveAction 并 fork，反而引入额外调度开销，实测性能通常下降 15%~40%。
更严重的是数据竞争风险：若左右子任务写入同一目标数组的不同区域，而 merge 任务又依赖它们完成，就必须显式 join() 等待，此时再 fork merge 就纯属冗余。正确做法是：
- 左子任务
fork() - 右子任务直接
compute()（即同步执行） - 调用
leftTask.join()拿回左结果 - 在当前线程内执行
merge(leftResult, rightResult, ...)
ForkJoinPool.commonPool() 在 Web 容器里可能悄悄失效
Spring Boot 或 Tomcat 环境下，ForkJoinPool.commonPool() 默认使用 daemon 线程，而某些容器会提前终止 daemon 线程导致任务静默丢失；另外 commonPool 不支持自定义拒绝策略和监控。
生产环境务必显式构造专用池：
ForkJoinPool pool = new ForkJoinPool(
Runtime.getRuntime().availableProcessors(), // parallelism
ForkJoinPool.defaultForkJoinWorkerThreadFactory,
(t, e) -> { logger.error("Task failed", e); },
true // asyncMode: 对归并排序这类 fork-join 密集型任务，设为 true 可略微提升吞吐
);
用完记得 pool.shutdown()，否则 JVM 无法正常退出——这点在单元测试里最容易被忽略。
