ForkJoinPool工作窃取非越小越好，需平衡任务粒度、线程数等；窃取仅在线程队列空且探测他队列时发生；优化关键在增大任务粒度以减少窃取频次。
ForkJoinPool 的工作窃取（Work-Stealing）本身是低开销设计，但“压缩到物理极限”是个误导性目标——它不是越小越好，而是要在任务粒度、线程数、队列结构和内存访问模式之间取得平衡。盲目压榨窃取开销，反而会引发更多上下文切换、伪共享或任务饥饿。真正有效的配置，是让窃取行为“几乎不发生”，而非让它“快得难以测量”。
一、先搞清窃取到底在什么时候发生
工作窃取只在以下两个条件同时满足时触发：
- 某个线程自己的双端队列（Deque）已空；
- 其他线程的队列非空，且该线程主动调用
pollAtWorkQueue()或tryPollSteal()尝试窃取。
也就是说，**窃取开销=空闲线程数 × 窃取探测频率 × 跨缓存行访问成本**。减少任一因子，都比优化单次窃取更快更有效。
二、用任务粒度堵住窃取入口（最有效）
这是压减窃取频次的根源手段。ForkJoinTask 只有在 fork() 出足够多子任务、且主线程快速 join() 完本地任务后，才可能陷入空闲并启动窃取。因此：
-
设置合理的阈值（threshold）：对数组排序、归并、遍历等场景，用
length 作不分割边界，比固定 <code>1或8更贴近 L1 缓存行大小（64 字节）与典型对象开销； -
避免“假分割”：不要为每个循环迭代都
fork()，改用for (int i = lo; i 批量处理，再统一 <code>join()； -
用
RecursiveAction替代RecursiveTask（若无需返回值），省去 join 时的同步等待与结果合并开销。
三、按硬件拓扑约束并行度，让“偷”变得不必要
ForkJoinPool 默认使用 ForkJoinPool.commonPool()，其并行度 = Runtime.getRuntime().availableProcessors() - 1。但这未必最优：
- 超线程（Hyper-Threading）下，逻辑核 ≠ 独立执行单元，
parallelism = 物理核数往往吞吐更高； - 若任务含 I/O 或阻塞调用（如数据库查询），需显式创建独立池：
new ForkJoinPool(4, ..., true)（true启用 asyncMode，禁用 LIFO 本地调度，更适合非计算型任务）； - 通过 JVM 参数
-XX:+PrintGCDetails -Xlog:safepoint*观察 GC 停顿与安全点争用，若频繁卡在no vm operation，说明线程数过多导致 safepoint 协调开销反超计算收益。
四、关闭无谓的“防护性”配置，释放底层效率
某些默认行为看似安全，实则引入隐蔽开销：
-
禁用
asyncMode = false下的双端队列栈语义：默认 LIFO 本地执行虽利于局部性，但会使任务分布不均；对均匀可分任务（如 map-reduce），构造池时传入true，启用 FIFO 窃取，反而提升负载均衡与缓存命中； -
不设
maxSpares和minSpares：动态调整线程数会触发addWorker()/tryTerminate()锁竞争，直接固定parallelism更稳； -
避免在任务中调用
Thread.sleep()、Object.wait()或同步块：这会让当前线程脱离 ForkJoinWorkerThread 生命周期，触发补偿机制（如创建替补线程），彻底破坏窃取模型。
不复杂但容易忽略：ForkJoinPool 的极致效率，从来不在“偷得多快”，而在“让每个线程始终有活干，且活刚好填满它的缓存和流水线”。参数只是杠杆，任务建模才是支点。
