并行流默认使用ForkJoinPool.commonPool()，其线程数=CPU核数，天然适配CPU密集型任务；仅当出现吞吐瓶颈且排除其他因素后才需调优，优先优化任务粒度与拆分行为而非盲目换池。
并行流（parallelStream()）底层默认使用 ForkJoinPool.commonPool()，它的配置直接决定变量吞吐量能否真正释放多核能力。优化关键不是“换池子”，而是让 commonPool 或自定义池的参数匹配任务特征——尤其是计算密度、数据规模和拆分行为。
优先确认是否真需要调优 commonPool
多数场景下，ForkJoinPool.commonPool() 已足够：它默认线程数 = Runtime.getRuntime().availableProcessors()，天然适配 CPU 密集型并行流任务。盲目替换为自定义池反而可能引入管理负担或配置偏差。
- 仅当出现明显吞吐瓶颈且排除了算法/IO/锁竞争等其他因素后，再考虑调优
- 若业务中混用大量虚拟线程（如 Spring Boot 3.3+ 默认启用），commonPool 在 JDK 21+ 中已自动适配轻量调度，通常无需干预
- 可通过
ForkJoinPool.commonPool().getParallelism()验证当前并行度是否等于物理核心数
控制并行流任务粒度：比改线程数更有效
吞吐量卡在“任务太碎”或“任务太粗”，远比线程数不对更常见。并行流会将数据源（如 List、Array）按 spliterator 拆分，但拆分逻辑受数据结构和阈值影响。
- 对
ArrayList等支持随机访问的集合，并行流倾向于均匀切片；但对LinkedList或自定义 Spliterator，可能退化为单线程遍历 - 避免在
map/filter中做阻塞操作（如 DB 查询、HTTP 调用），否则 commonPool 线程会被长期占用，窃取失效 - 若发现
ForkJoinPool.commonPool().getStealCount()接近 0，说明任务几乎同时完成或无法被窃取——此时应检查是否数据量小、计算极快，或拆分未生效
必要时创建专用 ForkJoinPool 并绑定并行流
当必须隔离资源（如防止慢任务拖垮公共池）、或需非默认并行度（如 CPU 密集+少量预热任务）时，可显式构造池并传入流操作：
- 构造示例：
new ForkJoinPool(8, factory, null, true)—— 8 线程、FIFO 模式（asyncMode=true更适合事件驱动类流处理） - 绑定方式：
list.parallelStream().forEach(...)无法指定池；需改用customPool.submit(() -> list.parallelStream().forEach(...)).join() - 更实用的是通过
ForkJoinPool.invoke()执行自定义RecursiveAction，把流逻辑封装进去，完全掌控 fork/join 边界
监控与验证真实吞吐提升
调优不是调参数，而是看效果。吞吐量变化必须落在可观测指标上：
- 用
System.nanoTime()测端到端耗时，对比串行流、默认并行流、自定义池并行流三组 - 采样
commonPool().getActiveThreadCount()和getRunningThreadCount()，确认线程是否真正活跃而非空转或阻塞 - JDK 自带
jcmd查看 ForkJoinPool 相关内存分配，异常增长可能提示任务对象泄漏VM.native_memory summary
