行相关操作。
那么，只要有终止方法一起，peek方法就一定会被执行吗？非也！看版本、看场景！ 比如在 JDK1.8版本中，下面这段代码中的peek方法会正常执行，但是到了 JDK17中就会被自动优化掉而不执行peek中的逻辑：
public void testPeekAndforeach() {
List<String> sentences = Arrays.asList("hello world", "Jia Gou Wu Dao");
sentences.stream().peek(sentence -> System.out.println(sentence)).count();
}
至于原因，可以看下JDK17官方API文档中的描述：
因为对于 findFirst、count之类的方法，peek操作被视为与结果无关联的操作，直接被优化掉不执行了。所以说最好按照API设计时预期的场景去使用API，避免自己给自己埋坑。
我们从peek的源码的注释上可以看出，peek的推荐使用场景是用于一些调试场景，可以借助peek来将各个元素的信息打印出来，便于开发过程中的调试与问题定位分析。
我们再看下peek这个词的含义解释：
既然开发者给它起了这么个名字，似乎确实仅是为了窥视执行过程中数据的变化情况。为了避免让自己踩坑，最好按照设计者推荐的用途用法进行使用，否则即使现在没问题，也不能保证后续版本中不会出问题。
字符串拼接明明有join，那么Stream中Collectors.join存在意义是啥
在介绍Stream流的收集器时，有介绍过使用 Collectors.joining来实现多个字符串元素之间按照要求进行拼接的实现。比如将给定的一堆字符串用逗号分隔拼接起来，可以这么写：
public void testCollectJoinStrings() {
List<String> ids = Arrays.asList("AAA", "BBB", "CCC");
String joinResult = ids.stream().collect(Collectors.joining(","));
System.out.println(joinResult);
}
有很多同学就提出字符串元素拼接直接用 String.join就可以了，完全没必要搞这么复杂。
如果是纯字符串简单拼接的场景，确实直接String.join会更简单一些，这种情况下使用Stream进行拼接的确有些大材小用了。 但是 joining的方法优势要体现在Stream体系中，也就是与其余Stream操作可以结合起来综合处理。String.join对于简单的字符串拼接是OK的，但是如果是一个Object对象列表，要求将Object某一个字段按照指定的拼接符去拼接的时候，就力不从心了——而这就是使用 Collectors.joining的时机了。比如下面的实例：
小结
好啦，关于Java Stream相关的内容点的补充，就聊到这里啦。如果需要全面了解Java Stream的相关内容，可以看我此前分享的文档。那么，你对Java Stream是否还有哪些疑问或者自己的独特理解呢？欢迎一起交流下。
传送门：
我是悟道，聊技术、又不仅仅聊技术~
如果觉得有用，请点赞 + 关注让我感受到您的支持。也可以关注下我的公众号【架构悟道】，获取更及时的更新。
期待与你一起探讨，一起成长为更好的自己。
