工作窃取不提升单任务性能，但能显著提升多任务混合场景下的CPU吞吐量；其核心是双端队列分工：线程从自身队列头部LIFO执行，空闲线程从他人队列尾部FIFO窃取，避免竞争并减少延迟。
直接结论：工作窃取本身不提升单任务性能，但能显著提升多任务混合场景下的 CPU 吞吐量——前提是任务可拆分、无阻塞、粒度合理。
为什么 ForkJoinPool 的 work-stealing 能提升吞吐量
核心在于双端队列（Deque）的分工设计：每个线程从自己队列的top（头部）LIFO 取任务执行，而空闲线程从其他线程队列的base（尾部）FIFO 窃取。这种分离避免了读写竞争，也保证被偷的任务通常是最早入队、等待最久的，从而减少整体延迟。
它不是靠“更快地跑一个任务”，而是靠“不让任何 CPU 核心空转”来提升吞吐。比如 8 核机器上，若 3 个线程提前完成，它们会立刻去偷剩下 5 个线程队列里的长尾任务，而不是干等。
常见错误现象：
- 任务执行中调用
Thread.sleep()或Object.wait()—— 窃取机制失效，线程卡住，其他线程无法接管 - 所有子任务几乎同时完成（如固定 size 拆分 + 均匀计算），导致窃取几乎不发生，退化为普通并行，但额外承担了 fork/join 开销
RecursiveTask 拆分时怎么设阈值才不拖慢速度
阈值（threshold）本质是串行/并行的切换开关。设得太小，fork/join 调度开销（对象创建、队列插入、上下文切换）会吃掉并行收益；设得太大，又浪费核数。
建议按以下方式估算并实测调整：
- 初始值用
totalSize / (Runtime.getRuntime().availableProcessors() * 2)，例如排序 1000 万整数、16 核机器，起始阈值可设为 312500 - 对计算特征敏感：纯算术（如累加）阈值可更大（10 万+）；含分支或缓存不友好操作（如随机内存访问）则需更小（1 万以内）
- 必须实测：用
ForkJoinPool.commonPool().getStealCount()观察窃取次数，理想区间是总任务数的 5%–30%，低于 5% 说明并行不足，高于 50% 很可能阈值过小
commonPool() 和自定义 ForkJoinPool 在 CPU 密集型任务里怎么选
绝大多数情况下，ForkJoinPool.commonPool() 就够用，且更安全——它默认线程数 = Runtime.getRuntime().availableProcessors()，正好匹配 CPU 密集型任务的理论最优值。
只有在以下明确场景才需要自定义：
- 你有多个独立的大任务流，且希望彼此隔离（比如 A 任务占满 commonPool，B 任务被饿死），此时用
new ForkJoinPool(parallelism)隔离资源 - 你明确知道任务含少量可控 I/O（如小文件读取），想略增线程数（如
availableProcessors() + 2），但注意：这已偏离纯 CPU 密集型假设 - 你需要捕获未处理异常（
commonPool()中抛出的异常会被静默吞掉），自定义池可通过UncaughtExceptionHandler捕获
反模式：new ForkJoinPool(100) 用于 CPU 密集任务——线程数远超核心数，上下文切换开销反超收益。
join() 调用顺序不当会导致隐式串行
join() 是同步阻塞点。如果在子任务 fork 后立即 join，等于强制等它结束才 fork 下一个，整个流程变成串行，还白扛 fork 开销。
正确模式是“先 fork 所有子任务，再统一 join”：
leftTask.fork(); // 启动左半部分 rightTask.fork(); // 同时启动右半部分 int leftResult = leftTask.join(); // 等待两者都完成 int rightResult = rightTask.join();
容易踩的坑：
- 递归任务里写成
leftTask.fork(); leftTask.join(); rightTask.fork(); rightTask.join();—— 实际是左→右串行 - 在
compute()内部调用外部同步资源（如synchronized块或ReentrantLock），导致线程阻塞在锁上，窃取线程无法介入 - 误用
invokeAll(leftTask, rightTask)却没意识到它底层仍是 fork + join 组合，不能省略逻辑判断
真正难的不是写对 fork/join，而是判断任务是否适合——如果拆分后子任务之间有强依赖、共享可变状态、或涉及网络/磁盘等待，工作窃取不仅无效，还会放大问题。这时候该换 CompletableFuture 或虚拟线程，而不是硬套 ForkJoinPool。
