我和Java 8 Stream相爱相杀的那些年

原文来自于：zha-ge.cn/java/48

我和Java 8 Stream相爱相杀的那些年

最近和朋友吃饭聊天，谈到Java Stream。大家沉默了3秒，像是在缅怀逝去的青春。有人说，Stream很香，但也经常“翻船”。我一激灵，想起了我和Stream的爱恨情仇。来，给大家八一八我的故事。

初识Stream：一见钟情

最早接触Stream，是因为某天项目里有个巨型List需要骚操作。以前foreach、if判断、临时List，写得又臭又长。有同事甩来一句：

我试了下，卧槽，真的牛。直接上代码（现在想想还挺想哭的，因为后来我的坑都是从这里埋下的）：

List<User> activeUsers = users.stream()
                                .filter(user -> user.isActive())
                                .collect(Collectors.toList());

以前得四五行，改成这样，谁看了不迷糊一下？Map、filter、collect，简直像乐高积木，拼一拼全都有。

表面风光，暗礁密布

但你以为这就是终点？太年轻了朋友。

慢慢来了花活，比如多条件筛选、去重、排序、分组……一不小心就写成了屎山链式：

List<User> result = users.stream()
  .filter(u -> u.getStatus() == 1)
  .distinct()
  .sorted(Comparator.comparing(User::getCreatedTime))
  .collect(Collectors.toList());

有时候加个peek自以为很优雅，其实在调试里哭晕。最骚的是，某次用完parallelStream()，第二天线上直接爆锅……

踩坑瞬间

盘点下“那些年我掉过的坑”：

• parallelStream()没搞清楚线程安全，搞坏全局变量；
• filter + map链太长，调试起来分分钟怀疑人生；
• collect(Collectors.toMap(...))健值重复直接爆异常；
• .findFirst()以为非空，其实Optional；
• peek本来想debug，结果副作用太骚，害人不浅。

还有一次，产品喊：“怎么页面顺序乱了？”我一看，原来用了Set加Stream，真的是自作聪明的典范。

最“光荣”的一战，是对一个大对象List分组汇总：

Map<String, List<User>> group = users.stream()
  .collect(Collectors.groupingBy(User::getGroupKey));
// ……

结果发现，Key有null，直接给我NullPointerException送上门，调半天才反应过来。

经验启示

踩了这么多雷，终于悟出点“人生指南”：

1. parallelStream 不是银弹 能不用就别用，线程安全的坑不是闹着玩的，如果要用，别乱改共享变量。
2. 链太长就拆开写 超过3步建议断一断，用变量存中间值，debug友好。
3. collect前多想一步 toMap一定要关注Key唯一，groupingBy注意null。
4. Optional要小心用 别动不动加get()，优雅的写法是配合isPresent/ifPresent。
5. peek慎用，仅为调试 真正有副作用的操作，别在Stream里搞，容易出事。

总结成表，送给刚接触Stream的朋友：

碎碎念结尾

回头看，Java Stream确实让代码短了，层次清晰了，脑子却更容易打结了。 像极了新买的多功能咖啡机，能煮能打奶泡，但一不留神就溢出来——工具还是得用明白才行。

要说Stream到底好不好用？我的答案是： 好用，但别迷信，别懒得思考。链高一尺，坑高一丈。

写到这手也酸了，今晚就到这吧。你也有Stream翻车故事？有空留言唠唠。