因为findFirst是短路终止操作，配合惰性求值，Pipeline在找到首个匹配元素后立即停止，后续元素不参与filter/map；而先collect再遍历需全量加载、新建集合、额外遍历，时间与内存开销均为O(n)。
为什么 filter + findFirst 比先 collect 再遍历快得多
因为 findFirst 是短路终止操作，配合惰性求值，整个 Pipeline 在找到第一个匹配元素后就立即停止，后续元素根本不会进入 filter 或 map 流程。而如果先用 collect(toList())，等于强制把全部数据拉进内存、生成新集合，再遍历——这在百万级数据中会多出 O(n) 时间和显著堆内存开销。
常见错误现象：Stream already closed 或 CPU 占用高但响应慢，往往是因为误用了非短路操作来替代短路逻辑。
- 优先用
findFirst、findAny、anyMatch、limit(1)替代collect后取第 0 个元素 - 避免在大数据流上使用
sorted()后接findFirst——sorted是有状态操作，必须全量加载并排序才能出结果 - 如果业务允许，
findAny在并行流中性能通常优于findFirst（不保证顺序，但省去同步开销）
map/filter 等中间操作真的不执行？那调试时怎么知道它卡在哪
它们确实不执行，只是组装 Pipeline 节点。所谓“卡住”，其实是终止操作触发后，JVM 才开始逐个元素驱动整条链。所以真正在意的不是中间操作本身，而是终止操作的类型和数据源特征。
使用场景：排查流处理慢，不能只看 filter 条件写得复杂，更要看终止操作是否引发全量计算或阻塞式 IO。
-
count()必须遍历全部元素，无法短路；比anyMatch慢一个数量级（尤其配合filter时） -
collect(Collectors.toList())会新建 ArrayList 并扩容，对千万级数据易触发多次数组复制 - 若终止操作是
forEach(System.out::println)，注意它是阻塞式消费，且不保证顺序（并行流下）
parallelStream() 不是万能加速器，什么时候反而更慢
并行流底层用 Fork/Join 拆分任务，但拆分+合并+线程调度本身有开销。当单个元素处理逻辑极轻（比如 num -> num * 2），或数据量小于 10000，或操作含锁/IO/状态共享时，并行流大概率比顺序流慢。
容易踩的坑：在 parallelStream() 中修改外部变量（如 ArrayList::add）、使用非线程安全的收集器、或在 map 里调用 new Random().nextInt()——这些都会导致竞态或隐式同步，性能断崖下跌。
- 确认数据源支持高效分片（
ArrayList、int[]可，LinkedList不可） - 终止操作优先用线程安全的收集器，如
Collectors.toConcurrentMap，而非手动同步 - 避免在中间操作中做任何阻塞调用（DB 查询、HTTP 请求），否则线程池会被拖垮
stream() 和 parallelStream() 共用同一个数据源会出什么问题
不会直接报错，但会触发“流已被消费”异常——因为 stream() 调用后返回的 Stream 实例是一次性对象，一旦被终止操作消耗，再次调用 iterator() 或重复 collect() 就抛 IllegalStateException: stream has already been operated upon or closed。
更隐蔽的问题是：你以为两次调用 list.stream() 是两个独立流，其实它们共享原始 list；如果中间操作里修改了 list（比如 filter 里调用了 list.remove()），第二次流的行为就不可预测。
- 永远不要复用已触发终止操作的 Stream 实例
- 需要多次处理，要么重新调用
list.stream()，要么把数据转为不可变副本（如list.copyOf()） - 别在 lambda 表达式里修改上游集合，这是并发和逻辑双重风险点
惰性求值不是银弹，它的优势只在「操作链设计合理 + 终止操作选对」时才真正生效。最常被忽略的是：有状态操作（sorted、distinct、limit）的代价差异极大，而开发者往往只盯着 filter 和 map 看。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
