要真正理解工作窃取机制，必须绕过Executors.newWorkStealingPool()，手动构建ForkJoinPool并配置parallelism、asyncMode等参数，结合带ID标识的ForkJoinTask子类与线程日志，观察originThread与当前线程不一致的现象来验证窃取发生。
直接用 Executors.newWorkStealingPool() 无法让你“实战掌握”工作窃取逻辑——它只是快捷创建一个 ForkJoinPool 实例，底层细节被封装掉了。真要理解变量窃取（应为“工作窃取”，非“变量窃取”），得绕过这个工厂方法，亲手配置、观察和调试 ForkJoinPool 的行为。
为什么 newWorkStealingPool 不适合学原理
这个方法返回的是一个 ForkJoinPool，但做了三件事：隐藏了并行度计算逻辑（默认为 Runtime.getRuntime().availableProcessors()）、禁用了自定义队列策略、屏蔽了任务窃取过程的可观测性。你调用它就像点外卖——能吃饱，但不知道菜怎么炒的。
- 它内部使用的是
ForkJoinPool.commonPool()的变体，不暴露 WorkQueue 实例 - 没有提供钩子（如
afterExecute）来监控任务是从哪来的（自己队列？还是被窃取？） - 所有任务提交后立即异步执行，无法插入断点或日志判断“此刻是否发生了窃取”
用自定义 ForkJoinPool 触发并验证窃取行为
真正动手，需要显式构造 ForkJoinPool，并配合可识别来源的任务：
- 设置较小的并行度（比如 2），用远超该数的任务量（如 100 个递归子任务），强制出现空闲线程
- 让每个任务记录所属线程名 + 执行时的队列状态（通过反射访问
ForkJoinPool.WorkQueue，或用 JMX 监控） - 在 compute() 中加入日志：
System.out.println(Thread.currentThread().getName() + " 执行 " + this + "，队列大小=" + getQueuedTaskCount()); - 观察输出：当某线程日志中出现 “ForkJoinPool-1-worker-1” 执行了一个明显不属于它初始分派范围的任务，且前一条日志是 “ForkJoinPool-1-worker-2” 刚 fork 出该任务——这就是窃取发生的确凿证据
关键参数与行为对照表
以下配置直接影响窃取频率和效果，必须手动控制：
-
parallelism：设为
Runtime.getRuntime().availableProcessors() - 1是常见起点，但设为 1 可彻底关闭窃取（只剩一个线程，无他人可偷） - asyncMode = false（默认）：队列按 LIFO 处理，利于缓存局部性；设为 true 则 FIFO，更倾向窃取旧任务
-
factory：可用自定义
ForkJoinWorkerThread子类，在onStart()和onTermination()中埋点，统计各线程处理了多少自己任务、多少窃取任务
用 ForkJoinTask 子类暴露窃取痕迹
不要只用 RecursiveTask 黑盒。写一个带身份标识的子类：
- 给每个任务加唯一 id 和创建线程名字段，在 fork() 时记录“父任务由谁创建”
- 在 compute() 开头打印：
"[id="+id+"] 来自 "+originThread+"，当前线程="+Thread.currentThread().getName() - 若发现
originThread ≠ Thread.currentThread().getName()，说明该任务被窃取执行 - 配合
ForkJoinPool.getQueuedTaskCount()或 JFR 事件，可确认窃取发生在哪个时刻
