一、Stream API为什么会被用歪？
很多Java开发者刚接触Stream API时，就像拿到新玩具的小朋友，恨不得把所有循环都改成Stream操作。这种热情可以理解，但往往会导致一些性能陷阱。比如下面这个常见的错误示例：
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
// 错误示范：多次调用终端操作
long count = numbers.stream().count(); // 第一次遍历
int sum = numbers.stream().mapToInt(i -> i).sum(); // 第二次遍历
这里的问题在于创建了两个Stream实例，导致集合被遍历了两次。对于小集合可能无所谓，但如果数据量很大，这种写法就会成为性能瓶颈。
二、那些不起眼的性能杀手
1. 无节制的中间操作
Stream的中间操作(lazy操作)虽然看起来很酷，但如果不加节制地使用，就会像俄罗斯套娃一样层层嵌套，最终影响性能：
List<String> names = getHugeNameList(); // 假设返回100万条数据
// 过度操作的Stream
List<String> result = names.stream()
.filter(name -> name.startsWith("A")) // 过滤
.map(String::toUpperCase) // 映射
.sorted() // 排序
.distinct() // 去重
.collect(Collectors.toList()); // 收集
这个例子中，每个中间操作都会产生新的Stream对象，消耗额外的内存和CPU资源。特别是sorted()和distinct()这类有状态的操作，性能开销更大。
2. 自动装箱的隐藏成本
Stream在处理基本类型时，如果不注意使用专门的流类型(如IntStream)，就会产生大量不必要的装箱拆箱操作：
List<Integer> numbers = getLargeNumberList(); // 假设返回大量整数
// 存在装箱问题的Stream
int sum = numbers.stream()
.filter(n -> n % 2 == 0) // 这里会发生Integer -> int的拆箱
.map(n -> n * 2) // 这里会发生int -> Integer的装箱
.reduce(0, Integer::sum); // 这里又会发生拆箱
改用IntStream可以避免这个问题：
// 优化后的版本
int sum = numbers.stream()
.mapToInt(Integer::intValue) // 转换为IntStream
.filter(n -> n % 2 == 0)
.map(n -> n * 2)
.sum(); // IntStream特有的终端操作
三、实战中的优化技巧
1. 选择合适的收集器
Collectors工具类提供了很多现成的收集器，但它们的性能差异很大：
List<String> names = getLargeNameList();
// 不太高效的收集方式
Set<String> nameSet = names.stream()
.collect(Collectors.toCollection(HashSet::new));
// 更高效的收集方式
Set<String> nameSet = names.stream()
.collect(Collectors.toSet()); // 内部会优化实现
对于需要合并多个结果的情况，可以考虑使用Collectors.teeing()(Java 12+)：
// 同时计算平均值和总和
DoubleSummaryStatistics stats = numbers.stream()
.collect(Collectors.teeing(
Collectors.averagingDouble(n -> n),
Collectors.summingDouble(n -> n),
(avg, sum) -> new DoubleSummaryStatistics() {{
accept(avg); accept(sum);
}}
));
2. 并行流的正确打开方式
并行流(parallel stream)不是银弹，使用不当反而会降低性能：
List<Integer> numbers = getNumbers();
// 错误的并行流用法
int sum = numbers.stream()
.parallel() // 强制使用并行
.filter(n -> n % 2 == 0)
.mapToInt(n -> n)
.sum();
适合使用并行流的场景：
- 数据量足够大(至少1万条以上)
- 处理每个元素的成本较高
- 操作是无状态的
- 不需要保持原有顺序
四、性能问题诊断与最佳实践
1. 如何诊断Stream性能问题
使用JMH(Java Microbenchmark Harness)进行基准测试是发现性能问题的好方法：
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Thread)
public class StreamBenchmark {
private List<Integer> data;
@Setup
public void setup() {
data = IntStream.range(0, 1000000)
.boxed()
.collect(Collectors.toList());
}
@Benchmark
public long sequentialStream() {
return data.stream().filter(n -> n % 2 == 0).count();
}
@Benchmark
public long parallelStream() {
return data.parallelStream().filter(n -> n % 2 == 0).count();
}
}
2. 最佳实践清单
- 避免长链式操作：中间操作最好不超过3-4个
- 优先使用基本类型流：IntStream/LongStream/DoubleStream
- 重用流：不要重复创建相同的流
- 谨慎使用并行流：先测试再使用
- 选择合适的收集器：了解Collectors类中的各种选项
- 考虑使用Spliterator：对于非常定制化的需求
记住，Stream API是为了让代码更简洁易读，而不是为了炫技。当性能成为关键因素时，传统的for循环可能仍然是更好的选择。
评论