什么时候该用 ForkJoinPool 而不是普通线程池
当任务天然可拆分、子任务间无强依赖、且单次计算耗时明显（比如 >10ms），ForkJoinPool 才有优势。它不是“并发更快”的万能解，而是为「递归分治」量身设计的——比如归并排序、树形结构遍历、大规模数组聚合。
常见误用场景：把 HTTP 请求、数据库查询这类 I/O 密集型任务塞进去，反而因线程饥饿拖慢整体；或者只拆出 2–3 个子任务，调度开销盖过收益。
- 适合：
RecursiveTask/RecursiveAction模式，任务能不断fork()+join() - 不适合：固定数量的独立任务（用
Executors.newFixedThreadPool更稳） - 注意：
ForkJoinPool默认使用守护线程，主线程退出后池会静默终止——需显式shutdown()+awaitTermination()
ForkJoinPool 的并行度设多少才不翻车
默认并行度是 Runtime.getRuntime().availableProcessors() - 1，看似合理，实则常踩坑：CPU 密集型任务确实适用，但一旦混入同步阻塞操作（如锁等待、简单 Thread.sleep()），实际活跃线程数骤降，吞吐直接腰斩。
更稳妥的做法是按任务类型反推：
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型：保持默认，或略调高 1–2（比如 8 核机器设为 8）
- 混合型（含短时阻塞）：设为
availableProcessors() * 2，靠工作窃取缓解阻塞影响 - 千万别硬写死
new ForkJoinPool(100)——线程过多引发上下文切换风暴，GC 压力飙升
示例：启动自定义池时明确传参：new ForkJoinPool(8, ForkJoinPool.defaultForkJoinWorkerThreadFactory, null, false)，最后的 false 表示不启用异步模式（避免 invoke() 阻塞时抢占其他任务队列）。
为什么 compute() 里调 join() 会卡死
这是最典型的死锁陷阱：当前线程在 compute() 中调用 join() 等待自己 fork 出的子任务，而子任务又因线程池满或窃取失败，被挂起等待当前线程去处理——形成闭环。
根本原因在于 ForkJoinPool 的工作窃取机制依赖线程主动让出 CPU，而非抢占式调度。一旦任务链过深或粒度太细，极易触发。
- 规避方法：确保每次
fork()后紧跟join()，不要交叉调用多个子任务的join() - 设置合理阈值：用
if (end - start ，THRESHOLD 一般取 1000–10000 元素，避免过度拆分 - 调试技巧：捕获
InterruptedException或观察线程堆栈中是否出现多层compute()嵌套
用 CompletableFuture 和 ForkJoinPool 混搭要注意什么
CompletableFuture 默认用 ForkJoinPool.commonPool()，但 commonPool 是全局共享的，你提交的 CPU 密集型分治任务可能和框架内部的异步任务（如 Spring 的 @Async）抢资源，导致双方都慢。
真实项目里，必须隔离池实例：
- 别依赖
commonPool()，显式创建专用池：private static final ForkJoinPool POOL = new ForkJoinPool(4); - 提交时用
CompletableFuture.supplyAsync(() -> {...}, POOL)，而不是无参重载 - 注意
thenApplyAsync这类后续操作，若不指定执行器，默认回落到commonPool()—— 必须显式传入你的POOL
容易忽略的一点：如果任务里混用了 synchronized 块或 ReentrantLock，锁竞争会放大线程阻塞效应，此时即便池够大，吞吐也上不去——分治的前提是子任务尽量无共享状态。
