直接 new ForkJoinPool() 易出问题，因其默认共享 commonPool 且线程数等于 CPU 核心数，I/O 阻塞易致饥饿、堆积或死锁；应显式创建独立实例并合理设置并行度。
为什么直接 new ForkJoinPool() 容易出问题
默认构造的 ForkJoinPool() 会创建与 CPU 核心数相等的并行线程，但实际任务可能含大量 I/O 或阻塞操作，导致线程饥饿、任务堆积甚至死锁。更关键的是，它使用的是公共的 ForkJoinPool.commonPool() —— 所有未指定池的 CompletableFuture、parallelStream() 都共享这个池，你的一次大任务可能拖慢整个应用的异步逻辑。
实操建议：
- 显式创建独立实例：
new ForkJoinPool(4)（按任务类型预估并发度，CPU 密集型一般设为Runtime.getRuntime().availableProcessors()） - 务必调用
shutdown()+awaitTermination()，否则 JVM 可能不退出 - 避免在
compute()中调用同步阻塞方法（如Thread.sleep()、数据库查询），必须用则考虑ForkJoinPool.ManagedBlocker
如何正确拆分任务：RecursiveTask vs RecursiveAction
选错子类会导致结果丢失或编译失败。RecursiveTask<T> 用于有返回值的场景（比如求和、查找最大值），必须重写 compute() 并返回 T；RecursiveAction 用于无返回的副作用操作（比如批量写文件、更新数组），compute() 返回 void。
常见错误现象：
- 本该用
RecursiveTask却继承RecursiveAction→ 编译报错“missing return statement” - 拆分阈值设得过大（如 100 万才切分）→ 递归深度浅，无法利用多核；过小（如每次只处理 1 个元素）→ 调度开销压倒计算收益
- 忘记调用
invoke()或fork()/join()组合 → 任务根本不执行
示例（整数数组求和）：
class SumTask extends RecursiveTask<Long> {
final int[] arr;
final int lo, hi;
SumTask(int[] arr, int lo, int hi) { this.arr = arr; this.lo = lo; this.hi = hi; }
protected Long compute() {
if (hi - lo <= 1000) { // 阈值可调
long sum = 0;
for (int i = lo; i < hi; i++) sum += arr[i];
return sum;
}
int mid = (lo + hi) / 2;
SumTask left = new SumTask(arr, lo, mid);
SumTask right = new SumTask(arr, mid, hi);
left.fork(); // 异步提交左任务
return right.compute() + left.join(); // 当前线程算右，再取左结果
}
}ForkJoinPool.submit() 和 invoke() 的行为差异
submit() 是异步非阻塞的，返回 ForkJoinTask，需手动 get() 等待；invoke() 是同步阻塞的，直接返回结果。两者底层都走同一个工作队列，但调用路径不同，影响异常传播和线程归属。
关键区别：
- 用
invoke()时，若任务抛异常，会原样抛出（如RuntimeException）；用submit().get()则包装成ExecutionException，需e.getCause()解包 -
invoke()优先由当前线程执行，适合主流程等待结果；submit()更适合“发出去就不管”，后续轮询或回调 - 不要混用：对同一任务反复
submit()会报IllegalStateException: task already executed
监控与调优：如何判断 ForkJoinPool 是否真的高效
光看 CPU 使用率没用。真正要盯的是 ForkJoinPool 的内部指标：队列长度、偷窃次数、活跃线程数。这些不暴露在 JMX 默认视图里，得靠 getQueuedTaskCount()、getStealCount()、getActiveThreadCount() 等方法主动查。
容易被忽略的点：
- 偷窃数（
steal count）持续为 0 → 任务拆分不均，某些线程一直空闲 - 队列积压（
queuedTaskCount）持续增长 → 拆分粒度太粗或线程数不足 - 频繁 GC 且
getRunningThreadCount()远低于并行度 → 任务中存在隐式内存泄漏（比如缓存了大对象引用）
调试时可在任务结束前打印：pool.getStealCount() + "/" + pool.getQueuedTaskCount()，观察趋势比单次值更有意义。
