parallelstream仅适用于数据量大、计算重、无依赖的场景；典型应用包括批量数值计算、大规模数据清洗、离线特征工程及密码学操作；须避开i/o任务、小数据集及含状态操作，优先使用collect而非foreach。
当任务满足“数据量大、计算重、无依赖”三个条件时，parallelStream 才值得启用。盲目开启反而拖慢性能，甚至引发线程安全问题。
适合并行流的典型业务场景
这些场景下，CPU 是瓶颈，且各元素可独立处理：
- 批量数值计算：如金融风控中对百万级用户做信用分重算、实时报价引擎中对数千只证券并行估值、图像处理中对像素矩阵逐点变换
- 大规模数据清洗与转换：ETL 流程中对日增 50 万+ 条日志做字段解析、脱敏、格式标准化（不含跨行逻辑）
- 离线模型特征工程：对用户行为宽表（千万级）并行生成统计类特征（如最近7天点击均值、品类偏好熵），每行特征计算互不干扰
- 密码学或编码操作：批量生成 JWT 签名、对大量文本做 Base64 或 SHA-256 哈希，纯 CPU 密集型且无状态
必须避开的高风险场景
这些情况用 parallelStream 不仅无效，还容易出错：
- 含 I/O 操作的任务：比如在 forEach 里查数据库、读配置文件、调远程 HTTP 接口——线程会阻塞，commonPool 被拖垮，整体吞吐反而下降
- 小数据集（：拆分、调度、合并的开销超过并行收益，实测常见于百条以内集合的 filter/map，顺序流更快
- 依赖顺序或共享变量的操作：例如用普通 ArrayList::add 收集结果、在 lambda 中修改 static 计数器、调用非线程安全的 SimpleDateFormat
- 含有状态中间操作：sorted()、limit()、findFirst() 在并行流中需全局排序或截断，会强制全量收集再处理，失去并行意义
验证是否该用并行流的实操建议
不要靠经验猜测，用真实数据和监控说话：
- 压测对比：同一数据集分别跑 stream() 和 parallelStream()，记录耗时、GC 次数、CPU 使用率，观察差异是否显著（建议提升 > 30% 才考虑）
- 检查操作链：只对 filter/map/mapToLong/sum/collect(toList()) 这类无状态终端操作启用；避免混入 peek()、forEach()（除非配合线程安全容器）
- 替换默认线程池（必要时）：若业务已有专用 ForkJoinPool 或 ExecutorService，可用 new ParallelStreamSupport(collection, customPool) 封装，避免挤占 commonPool 影响其他模块
- 优先用 collect 而非 forEach：例如用 .collect(Collectors.toList()) 替代 .forEach(list::add)，天然规避并发写冲突
