Stream是惰性、只读的,不修改原集合;重复使用会抛IllegalStateException;collect需选对收集器;并行流慎用;空值和null须显式处理。

Stream不会修改原始集合,但要注意中间操作的惰性
Java的Stream是只读视图,调用filter、map等方法不会改变原List或Set。但新手常误以为链式调用后原集合已“被处理”,结果后续还拿它做业务逻辑,导致数据不一致。
- 所有中间操作(如
filter、sorted、distinct)都是惰性的,只有遇到终端操作(如collect、forEach、count)才会真正执行 - 重复调用同一
Stream会抛IllegalStateException:“stream has already been operated upon or closed” - 如果需要多次遍历,得重新生成
Stream:用list.stream()而不是缓存一个Stream对象
collect(Collectors.toList())不是唯一选择,选错会导致性能问题
用collect收集结果时,Collectors.toList()返回的是不可变且无特定实现保障的List,JDK内部可能用ArrayList,也可能用其他实现——它不保证可扩容、不支持add,也不保留插入顺序(虽然当前版本实际保留)。
- 需要可变列表?直接用
new ArrayList(...)或Collectors.toCollection(ArrayList::new) - 要保持插入顺序且去重?用
Collectors.toCollection(LinkedHashSet::new),比先distinct()再toList()更高效 - 聚合为
Map时,注意Collectors.toMap在key重复时默认抛IllegalStateException,需显式传入合并函数,例如:(v1, v2) -> v1
并行流不是万能加速器,慎用在有状态或IO操作中
把stream()换成parallelStream()并不总能提速,尤其当元素少、操作轻量(如toString())、或含同步/IO(如System.out.println)时,反而因线程调度开销变慢,甚至引发竞态。
- 适合场景:CPU密集型、无状态、元素量大(通常 > 10000)、各元素处理相互独立
- 避免在
forEach里写System.out::println——输出会乱序,且锁竞争严重;改用peek+ 日志框架,或先collect再统一输出 - 不要在
parallelStream中修改共享变量(如int count = 0;然后forEach(x -> count++)),应改用AtomicInteger或reduce
空集合和null值处理不当会直接抛NPE
Stream.of(null)合法,但null进入map或filter后若未判空,终端操作时极易触发NullPointerException;而空集合调用stream()没问题,但误用findFirst().get()会炸。
立即学习“Java免费学习笔记(深入)”;
- 安全取首元素:用
findFirst().orElse(null)或findFirst().orElseThrow(() -> new RuntimeException("empty")) - 过滤前先剔除
null:stream().filter(Objects::nonNull) - 映射可能为
null的字段:用map(x -> x.getFoo()).filter(Objects::nonNull),别写map(x -> x.getFoo()).filter(f -> f != null)——后者在x为null时就NPE了
ListStream API的简洁背后藏着不少隐式契约:惰性求值、不可变性、线程模型约束、空值边界。写完一行names = Arrays.asList("Alice", null, "Bob", ""); List safeNames = names.stream() .filter(Objects::nonNull) // 先滤掉null元素 .filter(s -> !s.trim().isEmpty()) // 再滤掉空字符串 .map(String::toUpperCase) // 安全映射 .collect(Collectors.toList());
stream()链,最好反问一句——这个流谁负责关闭?中间有没有隐式依赖?终端操作会不会被意外跳过?










