什么时候该用 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() 阻塞时抢占其他任务队列）。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
为什么 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，锁竞争会放大线程阻塞效应，此时即便池够大，吞吐也上不去——分治的前提是子任务尽量无共享状态。
