parallelStream()仅在数据量≥CPU核数×1000、CPU密集型操作、数据源支持高效分割三前提同时满足时才真正提速；否则因调度开销、IO阻塞或低效分割反而更慢。
直接调用 parallelStream() 就能开启并行流，但“开开关”不等于性能提升——它只在满足条件时才真正压榨多核能力，否则可能更慢。
什么时候该用 parallelStream()
不是数据一多就上并行流。真正受益的场景需同时满足：
- 数据量够大：一般建议 ≥ CPU 逻辑核心数 × 1000（例如 16 核机器，至少 1.6 万条以上）；小数据集的分片、线程调度开销会反超收益
- 操作是 CPU 密集型：比如数值计算、字符串解析、复杂过滤；含数据库查询、文件读写、sleep 等 IO 或阻塞操作，会拖垮整个 ForkJoinPool
- 数据源支持高效分割：ArrayList、数组、IntStream 等可快速随机访问、均等切分；LinkedList、TreeSet、自定义迭代器若未重写 Spliterator.trySplit()，并行时可能退化为串行
怎么写才真正跑起来
基础写法很简单，但关键在后续操作是否适配：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用
list.parallelStream().filter(...).map(...).collect(...)替代list.stream()—— 这是最常用也最安全的方式 - 避免
forEach修改共享变量（如往 ArrayList.add()），它不保证线程安全；改用collect(Collectors.toList())或reduce - 优先选无状态操作：filter、map、flatMap 可自由并行；sorted、distinct、limit 属于有状态操作，需跨线程合并中间结果，开销大，慎用
- 对基础类型，直接用
IntStream.range(0, n).parallel()，比Stream.iterate(...).mapToInt(...)少装箱拆箱，实测快 30% 左右
并行度不是越大越好
默认使用 ForkJoinPool.commonPool()，线程数 = CPU 逻辑核心数 − 1。这不是固定值，要按任务类型微调：
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型：设为
Runtime.getRuntime().availableProcessors()，避免过度上下文切换 - 混合型或含少量 IO 等待：可尝试 ×1.5，但必须配合非阻塞设计（如异步 HTTP 客户端），否则只是增加争抢
- 不想影响全局 commonPool：显式创建自定义池，例如
new ForkJoinPool(12)，再 submit 并行流任务
终端操作选对很关键
同样查匹配项，findAny 和 findFirst 行为完全不同：
- 只要任意一个满足（如“是否存在活跃用户”）→ 用
findAny()：任意线程先返回即刻结束，无序但极快 - 必须取第一个（如“取排序后首条记录”）→ 用
findFirst()：强制维持顺序，其他线程结果会被丢弃，性能损失明显 - 百万数据实测：末位匹配时，findAny 耗时约 95ms，findFirst 约 210ms
