在java流中，使用.peek（）被视为仅用于调试目的，日志记录会被视为调试吗？[副本]

Question

因此，我有一个对象列表，我想要部分或全部被处理，我想要记录那些被处理的对象。

List<ClassInSchool> classes;
classes
.stream()
.filter(verifyClassInSixthGrade())
.filter(classHasNoClassRoom())
.peek(classInSchool -> log.debug("Processing classroom {} in sixth grade without classroom.", classInSchool)
.forEach(findMatchingClassRoomIfAvailable());

为了进一步解释，这个问题的关键在于：“不要以无意的方式使用API，即使它完成了您的当前目标。”我的问题是，每次使用peek（从调试流到验证整个链按设计工作并再次删除.peek（）为止）是否都是无意中的使用。因此，如果使用它作为记录流实际处理的每个对象的手段，则被认为是无意的使用。

Answer 1

code>peek的文档将其意图描述为

此方法的存在主要是为了支持调试，在调试中，您希望在元素流过管道中的某个点时看到这些元素。

窗体.peek(classInSchool->Log.Debug（“processing Clasment{}in sixth grade with Clasment.”,classInSchool）的表达式满足了这一意图，因为它是关于报告元素的处理情况的。您是使用日志框架，还是只打印语句（如文档示例中的.peek(E->System.Out.Println（“Filtered Value：”+e)）都无关紧要。在这两种情况下，重要的是意图，而不是技术方法。如果有人使用peek意图打印所有元素，那么它将是错误的，即使它使用了与文档示例(System.Out.Println)相同的技术方法。

文档并不要求您必须区分生产环境或调试环境，以删除对前者的peek用法。实际上，您的使用甚至可以实现这一点，因为日志框架允许您通过可配置的日志级别静音该操作。

我仍然建议记住，对于某些管道，插入peek操作可能会插入比实际操作更多的开销（或者在这样的程度上阻碍JVM的循环优化）。但是如果您没有遇到性能问题，您可以遵循老的建议，不要尝试优化，除非您有真正的原因…