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

Question

这个问题已经在这里有了答案：

• 在Java流中，peek真的仅用于调试吗？ 6个答案

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

考虑一个虚构的例子：

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

在这种情况下使用.peek（）是否会被视为API的意外使用？

为了进一步解释，在这个问题中 ，关键要点是： “即使实现了您的近期目标，也不要以意外的方式使用API​​。” 我的问题是，从调试流直到确认整个链条均按设计要求运行并再次删除了.peek（）之外，对peek的每次使用是否都是意外使用。 因此，如果将其用作记录流实际处理的每个对象的方式，则被认为是意外使用。

Answer 1

应避免偷看，因为某些终端操作可能无法调用，请参见此答案 。 在该示例中，最好是在forEach动作内部进行日志记录，而不是使用peek 。 在这种情况下进行调试意味着使用临时代码来修复错误或诊断问题。

Answer 2

peek的文档将意图描述为

存在此方法主要是为了支持调试，您需要在其中查看元素流过管道中特定点的情况。

形式为.peek(classInSchool -> log.debug("Processing classroom {} in sixth grade without classroom.", classInSchool)可以满足此目的，因为它与报告元素的处理有关。无论您使用日志记录框架还是仅打印语句，如文档示例中的.peek(e -> System.out.println("Filtered value: " + e)) 。如果有人使用peek来打印所有元素 ，那将是错误的，即使它使用与文档示例相同的技术方法（ System.out.println ）。

该文档没有强制您必须区分生产环境或调试环境，以消除前者的peek用法。 实际上，您的使用甚至可以满足要求，因为日志记录框架允许您通过可配置的日志记录级别使该操作静音。

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

Answer 3

在Java流中，使用.peek()被视为仅用于调试目的，日志记录会被视为调试吗？

这取决于您的日志记录代码是否将永久保留为代码。

只有您才能真正了解日志记录的真正目的...

另请注意， javadoc说：

在流实现能够优化某些或所有元素的产生的情况下（例如使用诸如findFirst类的短路操作，或者在count()描述的示例中），将不会为那些元素调用该操作。

因此，您很容易发现在某些情况下， peek并不是记录（或调试）管道的可靠方法。

通常，添加peek可能会更改管道的行为和/或JVM在当前或下一代JVM中对其进行优化的能力。

Answer 4

嗯，这有点解释。 意图并非总是容易确定的。

我认为添加API注释主要是为了避免过度使用peek ，而没有它几乎可以实现所有期望的行为。 对于开发人员来说，将其完全排除是太有用了，但是他们想明确一点，不要将其包括在内是不合格的认可。 他们看到了滥用的可能性，并试图解决它。

我怀疑-尽管我只是在推测-关于是否要完全包含它，人们意见不一，而在JavaDoc中包含带有警告的版本是妥协。

考虑到这一点，我认为我决定何时使用peek建议只是：除非有充分的理由，否则不要使用它。

就您而言，您绝对没有充分的理由。 您正在遍历所有内容，并将结果传递给findMatchingClassRoomIfAvailable方法（嗯，想必-您的示例不是很好）。 如果要为流中的每个项目记录某些内容，则只需将其记录在该方法的顶部即可。

是滥用吗？ 我不这么认为。 我会这样写吗？ 没有。