parallelStream 在大规模筛选中提升 CPU 利用率和速度的前提是：计算密集、数据量大、无顺序依赖三者同时满足；否则易引发线程安全问题、IO 阻塞或额外开销。
parallelStream 在大规模变量筛选中能否带来 CPU 优势，关键不在于“是不是并发”，而在于任务是否匹配其运行机制——它只在计算密集、数据量大、无顺序依赖这三者同时满足时，才真正释放多核 CPU 的潜力。
什么时候能明显看到 CPU 利用率和速度双提升？
以筛选百万级整数中满足复杂条件的元素为例（比如：x % 7 == 0 && Math.sqrt(x) > 100 && isPrime(x)）：
- 每个元素的判断逻辑耗时较长（属于计算密集型），CPU 计算成为瓶颈，而非内存或 GC
- 集合是 ArrayList 或数组，Spliterator 能高效拆分，避免退化成单线程遍历
- 筛选后只需 collect 到新 List，不依赖原始顺序，也不修改共享状态
- 目标机器有 4 核及以上，且 commonPool 未被其他任务长期占满
此时 parallelStream 通常能让 CPU 使用率接近核心数 × 100%，实测耗时可比 stream 快 2–4 倍。
哪些“筛选”场景反而会拖慢 CPU、甚至出错？
表面是过滤，但底层破坏了并行安全或效率前提：
- 用 forEach 修改外部 ArrayList 或 HashMap —— 多线程并发写引发 ConcurrentModificationException 或数据丢失
- 条件中调用远程 HTTP 接口或读取本地文件 —— IO 阻塞线程池，CPU 空转，整体吞吐下降
- 链式调用中含 sorted()、findFirst()、limit(10) —— JVM 必须等全部分片完成才能排序/截断，失去并行意义，还增加合并开销
- 自定义 Collector 没标记 CONCURRENT，或 combiner 方法用了静态计数器 —— 结果不可预测，每次运行值都不同
如何验证你这次筛选真受益于 CPU 并行？
别只看总耗时，要观察资源使用是否合理：
- 用 VisualVM 或 JMC 监控 ForkJoinPool.commonPool 的活跃线程数，确认峰值 ≥ CPU 核心数
- 对比 CPU 时间（不是墙钟时间）：jstack + async-profiler 可查各线程实际 CPU 占用是否均衡
- 小规模压测找临界点：从 1 万、5 万、10 万逐步加量，画出耗时曲线；若 1 万时 parallelStream 更慢，说明还没越过开销阈值
- 临时把 commonPool 并行度设为 1（-Djava.util.concurrent.ForkJoinPool.common.parallelism=1），若性能几乎不变，说明当前任务根本没并行起来
更稳更快的替代思路
如果业务逻辑难以规避顺序或 IO 依赖，硬上 parallelStream 反而得不偿失：
- 对数据先分区（如按 hash 取模），再用 ExecutorService 提交固定数量的 Callable 任务，可控性强
- IO 密集型筛选改用 CompletableFuture.allOf + 异步 HTTP 客户端，让线程在等待时不空转
- 需要保序且大数据量，考虑分块 + Stream.iterate + 自定义 Spliterator，兼顾可控与效率
- 高频调用场景，预热 ForkJoinPool（提交一个空任务），避免首次调用时线程创建延迟
并行筛选不是开关一开就快，而是要让任务结构、数据特征和硬件能力严丝合缝。多数时候，快的前提是“让它能真正并行”，而不是“让它看起来在并行”。
