工作窃取是parallel stream实现真正并行的底线：每个线程维护双端队列，本地处理（lifo）+跨队列尾部窃取（fifo），无锁、去中心化、主线程也参与，从而动态均衡负载、避免空转。
工作窃取不是“加分项”，而是Parallel Stream能真正并行起来的底线。没有它，再多核、再分治，线程依然会空转或阻塞——串行瓶颈根本打不破。
为什么串行瓶颈总在“负载不均”时爆发
传统线程池把任务扔进一个共享队列，所有线程争抢同一个入口。一旦某几个任务特别耗时（比如某个元素解析JSON极慢），其他线程很快处理完自己那份，只能干等——整体耗时由最慢的那个线程决定。
工作窃取直接绕开这个单点：每个线程有自己的双端队列，处理完本地任务后，不等待调度器指派，而是主动去别人队列尾部“拿一个走”。这相当于把长任务自动拆散、动态再分配，让所有CPU核心持续有活干。
工作窃取如何守住并行底线
- 无锁设计：线程只从自己队列头部取任务（LIFO），窃取方只从别人队列尾部取（FIFO），避免了共享队列的锁竞争和CAS重试开销
- 尾部窃取更安全：源线程刚压入的新任务往往局部性好、缓存热，留在尾部；窃取者拿走的是相对“冷”的旧任务，不影响原线程执行效率
- 去中心化调度：不需要全局协调器判断谁空闲、谁忙，每个线程自行探测+行动，扩展到上百核仍低延迟
- 主线程也参与：parallelStream 默认用 ForkJoinPool.commonPool()，而主线程本身也是工作线程之一——它不光发起任务，也会被分配、也会窃取，彻底消除“发起即等待”的串行惯性
没工作窃取，Parallel Stream 就只是“假并行”
实测中常见这类现象：
- 500万条日志过滤，8核机器跑 parallelStream 反而比 for 循环慢——因为多数线程早早空闲，只剩1个线程在扫大文件
- 自定义 Spliterator 没正确估计大小，导致 fork 出的任务粒度严重不均，窃取机制也救不了，最终退化成单线程执行
- 用了 synchronized 或阻塞IO操作，某个子任务卡住，整个 fork/join 链被拖住，窃取也无法跨过阻塞点
这些都不是 parallelStream “不好用”，而是工作窃取的前提被破坏了：任务可拆、无全局锁、无长阻塞、粒度合理。
关键不在“用不用”，而在“能不能被窃取”
写 parallelStream 代码时，真正要检查的不是“是否加了 parallel()”，而是：
- 数据源是否支持高效分割（ArrayList 可，LinkedList 不行）
- 中间操作是否无状态、无副作用（map/filter 安全，forEach + 共享变量危险）
- 终端操作是否兼容合并（collect(Collectors.toList()) 可合并，forEach(System.out::println) 不可）
- 有没有隐式同步或 I/O 等待卡住某个 fork 分支
只要其中一项不满足，工作窃取就失去作用对象——线程池再大，也变不出并行性。
