newWorkStealingPool() 返回 ForkJoinPool 实例，基于工作窃取算法调度任务，不支持 shutdownNow() 精确中断，适用于可分割的 CPU 密集型任务，不适用于阻塞 I/O 或强依赖场景。
newWorkStealingPool() 本质是 ForkJoinPool，不是普通线程池
它返回的是 ForkJoinPool 实例，底层用工作窃取（work-stealing）算法调度任务，不走 ExecutorService 的标准队列模型。这意味着：submit() 和 execute() 提交的 Runnable/Callable 会被包装成 ForkJoinTask 运行，但**不支持 shutdownNow() 的精确中断**——部分正在窃取执行的任务可能无法响应中断信号。
常见误用：把它当普通线程池反复 newWorkStealingPool() + shutdown()，结果触发大量 ForkJoinPool 内部线程重建开销，反而比 newFixedThreadPool() 更慢。
- 适合场景：大量可分割、轻量、无强依赖的 CPU 密集型任务（如并行流处理、递归分治计算）
- 不适合场景：含阻塞 I/O、需严格控制并发数、或任务间有共享状态且频繁同步
- 默认并行度 =
ForkJoinPool.getCommonPoolParallelism()，通常等于 CPU 核心数；可通过System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "8")调整（仅对公共池生效）
提交 Runnable/Callable 时，ForkJoinPool 不保证任务隔离
你传给 execute() 的 Runnable 会被转成 RunnableAdapter 包装的 RecursiveAction，但它**不会自动启用 fork/join 分治逻辑**——它只是被“扔进”工作窃取队列里执行，和普通线程池行为接近。真正发挥工作窃取优势，得靠 ForkJoinTask 子类（RecursiveTask/RecursiveAction）主动调用 fork() 和 join()。
典型错误现象：用 newWorkStealingPool().invokeAll(listOfCallables) 处理 1000 个独立 HTTP 请求，性能还不如 newFixedThreadPool(10)——因为网络 I/O 阻塞导致窃取线程空转，且每个 Callable 是原子提交，无法拆解。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：CPU 密集型任务才值得用分治；例如数组排序，用
RecursiveAction切分子数组再fork() - 若必须混用 I/O，建议把阻塞操作外包给专用
ExecutorService（如newCachedThreadPool()），本池只做纯计算 -
invoke()/invokeAll()会阻塞调用线程直到完成，而fork()是异步的；别在compute()里直接invoke()，容易栈溢出
并行流（parallelStream）默认就用 newWorkStealingPool() 的公共池
Java 8+ 中，list.parallelStream().map(...).reduce(...) 底层调用的是 ForkJoinPool.commonPool()，也就是 newWorkStealingPool() 所创建池的“兄弟”——它们共享同一套工作线程（除非显式传入自定义池）。这意味着：
- 你在代码中调用
newWorkStealingPool()创建新池，又同时跑大量并行流，会导致多个 ForkJoinPool 竞争 CPU，线程数翻倍，上下文切换陡增 - 公共池不可
shutdown()，它的生命周期绑定 JVM；想控制资源，只能用ForkJoinPool(int parallelism)构造器手动建池，并传给stream().parallel().unordered().collect(...)的Collector.of()或Arrays.parallelSort()的重载方法 - 监控公共池负载？查
ForkJoinPool.commonPool().getActiveThreadCount()和getQueuedTaskCount()，但注意这些值是近似值，非实时精确
别忽略 ForkJoinPool 的异常传播机制
ForkJoinPool 对未捕获异常的处理和普通线程池不同：子任务抛出的异常会沿 join() 调用链向上抛，但如果主任务没调 join()（比如只用 fork() 后就返回），异常会静默丢失，或在最终 invoke() 时集中爆发。更隐蔽的问题是：同一个池里多个任务的异常可能互相覆盖 ForkJoinTask.getException() 返回值。
- 调试技巧：在
compute()方法末尾加if (isCompletedAbnormally()) System.err.println(getException()); - 生产建议：所有
RecursiveTask的compute()必须有 try-catch 包裹，把业务异常转为返回值或日志，避免依赖异常传播 - 注意
ForkJoinPool.ManagedBlocker：当你必须在compute()里做阻塞操作（如锁等待），要用它包装，否则池可能误判线程“卡死”而启动额外线程
工作窃取不是银弹。它省掉的是任务排队等待时间，但换来的是更复杂的线程协作逻辑和更难调试的异常路径。真正提升效率的关键，从来不是换一个 Executor，而是让任务本身具备可分割性、低耦合、无共享突变状态——这些，代码结构比线程池选择重要得多。
