Executors.newWorkStealingPool 适用于可递归拆分的CPU密集型任务，依赖工作窃取实现隐式负载均衡；对天然不均衡的独立任务效果差，应预处理分组并分层调度。
Executors.newWorkStealingPool 不是用来“均衡耗时变量”的，它本身不分析或调整任务耗时，而是靠工作窃取机制动态平衡线程负载——前提是任务能被合理拆分、且整体偏向 CPU 密集型。直接拿它处理不均衡的原始任务（比如一批执行时间从几毫秒到几秒不等的独立 Callable），效果往往不如 newFixedThreadPool，甚至更差。
它真正起作用的前提：任务可递归切分
newWorkStealingPool 的底层是 ForkJoinPool，优势不在“调度不同耗时的任务”，而在让一个大任务主动 fork 成多个子任务，由空闲线程去窃取执行。例如：
- 对 1000 万个整数排序 → 可切分为左右两半，各自 fork 排序，再 merge
- 遍历一棵深层树做计算 → 每个子树作为子任务 fork 出去
- 图像像素批量处理 → 按区域切块，每块封装为 RecursiveAction
这时，即使某块数据局部复杂（耗时长），其他线程也能从队列里“偷”走轻量块来填满 CPU，实现隐式负载均衡。但如果你只是 submit 100 个互不相关的 Runnable，每个耗时差异大，它就只是把它们扔进不同线程执行，不拆解、不重调度，无法改善“有的线程早做完干等，有的还在卡着”的问题。
面对天然不均衡的任务，正确做法是预处理+分层调度
当你的任务本身不可分割（如 HTTP 请求、DB 查询、文件解析），但耗时差异大，别强塞 newWorkStealingPool。应分两步：
- 用轻量预估或历史统计，把任务按耗时粗略分组（例如：快任务 500ms）
- 为快/中任务配 newWorkStealingPool（专注吞吐），慢任务单独交给 newFixedThreadPool（控制资源占用，防拖垮）
- 必要时加异步编排：用 CompletableFuture.anyOf() 或 allOf() 协调不同池的结果
避免典型误用：别把它当通用线程池反复创建
常见反模式：
- 每次请求都 newWorkStealingPool(4)，处理完立刻 shutdown() → 触发大量 ForkJoinWorkerThread 创建/销毁开销
- 用 invokeAll 提交 500 个含阻塞 I/O 的 Callable → 窃取线程因等待而空转，CPU 利用率暴跌
- 未设并行度，依赖默认值（=CPU 核心数），但实际任务含较多同步或锁竞争 → 真实并发远低于预期
建议：全局复用单例池，如 Executors.newWorkStealingPool(Runtime.getRuntime().availableProcessors())；若需定制并行度，用系统属性或构造带 parallelism 的 ForkJoinPool 实例。
验证是否真起效：看线程利用率和 ForkJoinPool 状态
光看总耗时不准确。应监控：
- 活跃线程数波动是否平缓（jstack 或 JMX 中查看 pool.getActiveThreadCount()）
- 任务队列平均长度是否趋近于 0（说明窃取及时，无积压）
- 对比 FixedThreadPool：相同任务下，CPU 使用率是否更接近 100%，GC 次数是否未明显上升
如果发现 newWorkStealingPool 下线程经常 BLOCKED 或 WAITING，基本说明任务不适合——该换策略了。
