直接 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></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 <h3>ForkJoinPool.submit() 和 invoke() 的行为差异</h3>
<p><code>submit()</code> 是异步非阻塞的，返回 <code>ForkJoinTask</code>，需手动 <code>get()</code> 等待；<code>invoke()</code> 是同步阻塞的，直接返回结果。两者底层都走同一个工作队列，但调用路径不同，影响异常传播和线程归属。</p>
<p>关键区别：</p>
<ul>
<li>用 <code>invoke()</code> 时，若任务抛异常，会原样抛出（如 <code>RuntimeException</code>）；用 <code>submit().get()</code> 则包装成 <code>ExecutionException</code>，需 <code>e.getCause()</code> 解包</li>
<li>
<code>invoke()</code> 优先由当前线程执行，适合主流程等待结果；<code>submit()</code> 更适合“发出去就不管”，后续轮询或回调</li>
<li>不要混用：对同一任务反复 <code>submit()</code> 会报 <code>IllegalStateException: task already executed</code>
</li>
</ul>
<h3>监控与调优：如何判断 ForkJoinPool 是否真的高效</h3>
<p>光看 CPU 使用率没用。真正要盯的是 <code>ForkJoinPool</code> 的内部指标：队列长度、偷窃次数、活跃线程数。这些不暴露在 JMX 默认视图里，得靠 <code>getQueuedTaskCount()</code>、<code>getStealCount()</code>、<code>getActiveThreadCount()</code> 等方法主动查。</p>
<p>容易被忽略的点：</p>
<ul>
<li>偷窃数（<code>steal count</code>）持续为 0 → 任务拆分不均，某些线程一直空闲</li>
<li>队列积压（<code>queuedTaskCount</code>）持续增长 → 拆分粒度太粗或线程数不足</li>
<li>频繁 GC 且 <code>getRunningThreadCount()</code> 远低于并行度 → 任务中存在隐式内存泄漏（比如缓存了大对象引用）</li>
</ul>
<p>调试时可在任务结束前打印：<code>pool.getStealCount() + "/" + pool.getQueuedTaskCount()</code>，观察趋势比单次值更有意义。</p></long>
