ForkJoinPool默认构造常跑不快，因其并行度为CPU核数减1且任务粒度粗时窃取失效；需按子任务耗时调优阈值、避免阻塞、慎用commonPool，并在不可递归拆分或计算过轻时改用其他并发方案。
ForkJoinPool 的工作窃取不是“自动加速器”，它只在任务可递归拆分、且子任务间无强依赖时才真正生效；盲目套用反而因队列开销和线程调度拖慢性能。
为什么直接 new ForkJoinPool() 常常跑不快
默认构造的 ForkJoinPool() 使用 ForkJoinPool.commonPool() 的并行度（通常是 Runtime.getRuntime().availableProcessors() - 1），但这个值对 I/O 密集或内存敏感型计算并不友好。更关键的是：如果任务拆分粒度太粗（比如阈值设为 10000），线程很快耗尽自己队列的任务，却因其他线程还在处理长子任务而无法有效窃取——此时“窃取”形同虚设，大量线程空转。
- 实际场景中，
THRESHOLD应基于子任务平均执行时间调整，而非数据量绝对值；建议先用小样本压测，观察ForkJoinPool.getStealCount()是否显著增长 - 避免在
compute()中调用阻塞操作（如Thread.sleep()、数据库查询、Object.wait()），这会卡住整个工作线程，导致窃取失效 -
ForkJoinWorkerThread不继承调用者线程的ThreadLocal，若依赖上下文（如事务 ID、用户信息），必须显式传递参数，不能靠继承
RecursiveTask.compute() 里 fork() 和 join() 的顺序陷阱
错误写法是先 fork() 两个子任务，再 join() 它们——这会让当前线程串行等待，失去并行意义。正确模式是“左 fork，右 compute，再 join 左”或“左右都 fork，最后一起 join”，但必须保证所有 fork() 在任意 join() 前完成。
- 推荐结构：
left.fork(); int rightResult = right.compute(); int leftResult = left.join(); return leftResult + rightResult; - 切忌在
join()后再调用fork()，否则该子任务可能被丢弃（ForkJoinPool 不保证未 fork 任务的调度） - 若子任务抛异常，
join()会抛出ExecutionException包装的原始异常；需在compute()内捕获并决定是否继续拆分或返回默认值
commonPool() 和自定义池的关键区别在哪
ForkJoinPool.commonPool() 是 JVM 全局共享的，所有未指定池的 parallelStream()、CompletableFuture 都往里扔任务。当你的海量数据计算和 Web 请求的异步回调共用它时，极易相互干扰——一个大计算任务占满线程，导致 HTTP 超时。
- 生产环境务必用自定义池：
new ForkJoinPool(4)（按 CPU 核心数 × 1.2~1.5 试配），并显式传入pool.invoke(task) - 自定义池可设置
asyncMode = true（即new ForkJoinPool(parallelism, ..., true)），启用 FIFO 模式，更适合任务到达时间不均、需降低延迟的场景（如实时流处理） - 关闭池前必须调用
shutdown()+awaitTermination()，否则 JVM 退出时子线程可能被强制中断，join()返回未定义值
真正难的不是写对 fork() 和 join()，而是判断什么时候不该用 ForkJoinPool：当子任务需要频繁跨线程共享状态、或单次计算本身已接近纳秒级时，工作窃取带来的双端队列管理开销会盖过并行收益。这时候，ParallelStream 或固定大小的 ThreadPoolExecutor 可能更稳。
