ForkJoinPool适合计算密集型、可递归拆分且无强依赖的任务，核心优势是工作窃取和分治支持；不适用于I/O密集、强耦合或超小任务。
ForkJoinPool 适合处理可递归拆分、计算密集型、无强依赖关系的任务。它不是通用线程池，核心优势在于“工作窃取”（Work-Stealing）机制和对分治（Divide-and-Conquer）模型的原生支持，特别适合任务能自然切分成子任务、且子任务之间基本不共享状态或只需少量同步的场景。
适合的任务类型：计算密集型 + 可分治
典型例子包括：
- 大规模数组排序（如并行归并排序、快速排序）
- 大矩阵乘法、数值积分、分形图像渲染
- 树/图的深度优先遍历、JSON/XML 大文档结构化解析（递归解析节点）
- 递归搜索（如八皇后、迷宫求解）、分支限界算法
关键判断点：任务能否在逻辑上不断“fork”成更小的同类子任务，直到达到阈值（threshold）后直接“compute”；整个过程基本不阻塞、不频繁 I/O、不强依赖外部服务。
不适合的任务类型：I/O密集或强耦合操作
ForkJoinPool 的线程默认是守护线程，且线程数通常设为 CPU 核心数（或略多），不适用于：
立即学习“Java免费学习笔记（深入）”；
- 数据库查询、HTTP 调用、文件读写等阻塞型 I/O 操作（会空耗工作线程，拖慢整体吞吐）
- 需要严格顺序执行或强状态共享的任务（如共享可变计数器未加锁，易出错；ForkJoinTask 不鼓励共享可变状态）
- 单个任务极小（如只做几次加法），拆分开反而增加 fork/join 开销，得不偿失
这类任务更适合用 ThreadPoolExecutor 配合 CompletableFuture 或自定义线程池。
使用要点：合理设置阈值 + 优选 RecursiveTask/RecursiveAction
避免过度拆分，需通过实验确定合适的 threshold（例如数组长度
- 继承 RecursiveTask
（有返回值）或 RecursiveAction（无返回值） - 重写 compute() 方法：先判断是否达阈值 → 是则直接计算；否则 fork 子任务，再 join 获取结果
- 推荐用 ForkJoinPool.commonPool() 处理短生命周期任务；长期/专用任务建议创建独立 ForkJoinPool 实例，避免干扰公共池
注意工作窃取的实际效果
当某个线程提前完成自己的任务队列，会自动从其他线程双端队列的**尾部**偷任务（避免竞争），提升 CPU 利用率。但这要求子任务粒度适中：
- 太粗 → 窃取机会少，负载不均
- 太细 → 队列管理、线程调度开销上升，甚至不如单线程
实践中常以“预计耗时几毫秒到几十毫秒”的子任务为宜，具体需结合数据规模与 CPU 特性压测调整。
