Java Stream API 深度实战——并行流陷阱、性能反例、正确打开方式

适读人群：用了几年 Java 但对 Stream 一知半解的工程师 | 阅读时长：约14分钟 | 核心价值：把 Stream 最容易踩的坑说清楚，配合反例

---

Stream API 是 Java 8 带来的变化里，我用得最多的特性之一。但我也见过太多被 Stream 坑过的代码——有些是性能问题，有些是逻辑错误，还有一些是把简单的事情搞复杂了。

这篇文章不从头介绍 Stream，默认你已经会用基础 API，我只说那些容易踩坑的地方。

---

一、Stream 不是银弹：什么时候别用

Stream 不是所有情况都适合用。先说清楚不该用的场景：

场景1：需要提前退出的循环

// 用传统循环更清晰
List<User> users = getUsers();
User target = null;
for (User user : users) {
    if (someComplexCondition(user)) {
        target = user;
        break;  // 找到了就退出
    }
}

// Stream 版本强行用 filter().findFirst()，语义上还好，但如果逻辑复杂会变得难读
Optional<User> optTarget = users.stream()
    .filter(u -> someComplexCondition(u))
    .findFirst();

两种写法都可以，但如果逻辑非常复杂，传统 for 循环反而更直观。Stream 不是越用越好，适合的时候用。

场景2：需要修改外部状态

// 反模式！在 Stream 里修改外部变量
List<String> results = new ArrayList<>();
users.stream()
    .filter(u -> u.isActive())
    .forEach(u -> results.add(u.getName()));  // 在 forEach 里修改外部 List，有线程安全风险

// 正确做法：用 collect
List<String> results = users.stream()
    .filter(User::isActive)
    .map(User::getName)
    .collect(Collectors.toList());

场景3：链式操作里混入了 IO 或副作用

// 危险！在 Stream 链里做数据库查询
users.stream()
    .map(user -> userRepository.findDetailById(user.getId()))  // 每个元素都查一次数据库！
    .collect(Collectors.toList());
// 如果 users 有1000个，这里查了1000次数据库，N+1问题

// 更好的做法：批量查询，然后用 Stream 处理内存数据
List<Long> ids = users.stream().map(User::getId).collect(Collectors.toList());
Map<Long, UserDetail> detailMap = userRepository.findDetailByIds(ids)
    .stream().collect(Collectors.toMap(UserDetail::getId, d -> d));
List<UserDetail> results = users.stream()
    .map(u -> detailMap.get(u.getId()))
    .collect(Collectors.toList());

---

二、并行流：被过度推销的特性

并行流（parallelStream()）是我见过被误用最多的 Stream 特性。

// 直观上感觉：并行=快，应该默认用
List<Result> results = bigList.parallelStream()
    .map(item -> process(item))
    .collect(Collectors.toList());

但实际上，并行流能带来性能提升的条件非常严苛：

1. 数据量足够大（通常需要几万以上）
2. 每个元素的处理是 CPU 密集型（时间够长，至少几十微秒以上）
3. 元素之间没有依赖关系
4. 不涉及 IO 操作

---

陷阱1：数据量小时，并行流比串行慢

// 我测试过的一个反例：10个元素，纯计算
List<Integer> small = IntStream.range(0, 10).boxed().collect(Collectors.toList());

// 串行：~0.03ms
small.stream().map(i -> i * i).collect(Collectors.toList());

// 并行：~1.2ms（线程创建、任务分割、结果合并的开销远大于计算本身）
small.parallelStream().map(i -> i * i).collect(Collectors.toList());

并行流底层用的是 ForkJoinPool.commonPool()，有线程管理开销。数据量小的时候，这个开销远大于并行带来的收益。

陷阱2：IO 操作 + 并行流 = 灾难

// 千万不要这么写
List<UserDetail> details = userIds.parallelStream()
    .map(id -> httpClient.getUserDetail(id))  // 每个元素发一个 HTTP 请求
    .collect(Collectors.toList());
// 问题：用的是 ForkJoinPool.commonPool()，这是全局共享的线程池
// 你的 IO 操作把这个线程池占满了，影响其他地方用这个线程池的代码
// 而且你无法控制并发数，可能瞬间发出几百个 HTTP 请求把下游打挂

IO 操作的并发，用 ExecutorService 或者 CompletableFuture 来控制，不要用并行流。

陷阱3：并行流影响其他线程

// ForkJoinPool.commonPool() 是全局的
// 你的并行流和 Spring 的异步任务、其他业务代码的并行流共享这个线程池
// 一个地方饿死了线程池，全局都受影响
BigList.parallelStream()
    .map(i -> heavyCompute(i))  // 把 commonPool 的线程都占满了
    .collect(Collectors.toList());

// 如果确实需要大量并行计算，用自定义的 ForkJoinPool
ForkJoinPool customPool = new ForkJoinPool(4);  // 只用4个线程
customPool.submit(() -> 
    bigList.parallelStream()
        .map(i -> heavyCompute(i))
        .collect(Collectors.toList())
).get();

我的原则：默认不用并行流，只在明确测试过性能提升、且数据量大、CPU密集型的场景才用。

---

三、collect 的正确姿势

collect 是 Stream 里最灵活也最常用的终止操作，但有几个容易写错的地方：

// 分组
Map<String, List<User>> byDept = users.stream()
    .collect(Collectors.groupingBy(User::getDepartment));

// 分组并计数
Map<String, Long> countByDept = users.stream()
    .collect(Collectors.groupingBy(User::getDepartment, Collectors.counting()));

// 分区（按 boolean 分成两组）
Map<Boolean, List<User>> partitioned = users.stream()
    .collect(Collectors.partitioningBy(User::isActive));

// 转成 Map，注意：如果有重复 key 会抛异常！
Map<Long, User> userMap = users.stream()
    .collect(Collectors.toMap(User::getId, u -> u));
// 安全版本，重复 key 时保留最新的：
Map<Long, User> userMap = users.stream()
    .collect(Collectors.toMap(User::getId, u -> u, (a, b) -> b));

// joining
String names = users.stream()
    .map(User::getName)
    .collect(Collectors.joining(", ", "[", "]"));  // "[张三, 李四, 王五]"

---

四、常见性能反例

反例1：重复计算

// 慢！每次 filter 都调 getName()，getName() 如果有开销就浪费了
users.stream()
    .filter(u -> u.getName().length() > 3)
    .sorted(Comparator.comparing(u -> u.getName()))  // getName() 调用次数 = n*log(n)
    .collect(Collectors.toList());

// 快：先提取计算结果，避免重复计算
users.stream()
    .filter(u -> u.getName().length() > 3)
    .sorted(Comparator.comparing(User::getName))  // 注意：这里方法引用内部也会多次调用
    // 如果 getName() 开销真的很大，用 map 先提取
    .collect(Collectors.toList());

反例2：不必要的装箱

// 慢：Integer 装箱
List<Integer> nums = Arrays.asList(1, 2, 3, 4, 5);
int sum = nums.stream().mapToInt(Integer::intValue).sum();  // 还好，mapToInt 有了

// 但这个更糟糕：
int[] arr = {1, 2, 3, 4, 5};
int sum = Arrays.stream(arr)  // IntStream，无需装箱
    .sum();

// 数值密集型计算，用 IntStream/LongStream/DoubleStream，避免装箱
IntStream.range(0, 1000000)
    .filter(i -> i % 2 == 0)
    .sum();

反例3：collect 转换再 stream

// 不好：中间产生了不必要的 List
List<String> names = users.stream()
    .map(User::getName)
    .collect(Collectors.toList());  // 这里收集成 List

names.stream()  // 然后又 stream
    .filter(name -> name.length() > 3)
    .forEach(System.out::println);

// 好：一个 Stream 链到底
users.stream()
    .map(User::getName)
    .filter(name -> name.length() > 3)
    .forEach(System.out::println);

---

五、flatMap 的正确用法

flatMap 是 Stream 里功能最强但最容易用错的操作符：

// 场景：每个部门有多个员工，把所有员工展开成一个 Stream
List<Department> departments = getDepartments();

// 正确：flatMap 把 Stream<List<Employee>> 展平成 Stream<Employee>
List<Employee> allEmployees = departments.stream()
    .flatMap(dept -> dept.getEmployees().stream())
    .collect(Collectors.toList());

// 嵌套集合：每个员工有多个技能，找出所有独特技能
Set<String> allSkills = departments.stream()
    .flatMap(dept -> dept.getEmployees().stream())
    .flatMap(emp -> emp.getSkills().stream())
    .collect(Collectors.toSet());

---

六、Optional 和 Stream 的结合

Java 9+ 的 Optional 有 stream() 方法，可以和 Stream 无缝结合：

// 场景：有些 userId 可能对应不到 User（已注销），过滤掉这些
List<User> users = userIds.stream()
    .map(id -> userRepository.findById(id))  // 返回 Optional<User>
    .filter(Optional::isPresent)
    .map(Optional::get)
    .collect(Collectors.toList());

// Java 9+ 更优雅的写法
List<User> users = userIds.stream()
    .map(id -> userRepository.findById(id))
    .flatMap(Optional::stream)  // Optional.stream() 返回0或1个元素的 Stream
    .collect(Collectors.toList());

---

Stream 用好了，代码确实更简洁，但要建立一个原则：Stream 是为了让代码更易读，如果写出来比传统 for 循环更难理解，那就用 for 循环。 复杂度不是炫技的资本。

下一篇写 Optional 的深度实战，这个特性被很多人只当成"避免空指针的工具"用，实际上它对代码风格的影响远不止于此。