本文探讨了Java 8到Java 9版本升级过程中，Stream API中带有副作用的中间操作（如`map`中的打印）在`count()`终端操作下行为不一致的问题。核心原因在于Java 9对`count()`的优化可能跳过不影响最终结果的中间操作。文章强调了避免在中间操作中依赖副作用的重要性，并提供了相应的最佳实践，以确保代码行为的可预测性。
引言
Java 8引入的Stream API极大地简化了集合数据的处理，以其声明式、函数式的编程风格广受欢迎。然而，在从Java 8迁移到Java 9或更高版本时，开发者可能会遇到一些意料之外的行为差异，特别是在涉及Stream中间操作的“副作用”时。本文将深入探讨一个典型的案例：在Java 9及更高版本中，当使用count()作为终端操作时，某些带有副作用的中间操作可能不会被执行，这与Java 8的行为有所不同。
问题现象：Java 8与Java 9的行为差异
考虑以下Java代码示例，它构建了一个Stream管道，并在其中一个map操作中包含了一个打印语句，最终以count()操作结束：
import java.util.*;import java.util.function.Predicate;import java.util.stream.Stream;public class TestingJavaStream { public static void main(String[] args) { Message message = new Message(); message.setName("Hello World!"); Stream messageStream = streamNonnulls(Collections.singleton(message)) .filter(not(Collection::isEmpty)) .findFirst() .map(Collection::stream) .orElseGet(Stream::empty); System.out.println("Number of messages printed are " + messageStream .map(TestingJavaStream::print) // 带有副作用的中间操作 .count()); // 终端操作 } public static class Message { private String name; public String getName() { return this.name; } public void setName(String name) { this.name = name; } @Override public int hashCode() { /* 省略 */ return 0; } @Override public boolean equals(Object obj) { /* 省略 */ return true; } @Override public String toString() { return "Message [name=" + name + "]"; } } @SafeVarargs public static Stream streamNonnulls(T... in) { return stream(in).filter(Objects::nonNull); } @SafeVarargs public static Stream stream(T... in) { return Optional.ofNullable(in) .filter(arr -> !(arr.length == 1 && arr[0] == null)) .map(Stream::of) .orElseGet(Stream::empty); } public static Predicate not(Predicate p) { return (T x) -> !p.test(x); } public static Message print(Message someValue) { System.out.println("Message is :: "+someValue.toString()); // 副作用：打印 return someValue; }}
在Java 8环境下执行上述代码，控制台会输出：
立即学习“Java免费学习笔记（深入）”；
Message is :: Message [name=Hello World!]Number of messages printed are 1
这表明print方法被调用了，其副作用（打印消息）得以执行。
然而，在Java 9及更高版本（例如Java 17）环境下执行相同的代码，控制台可能只输出：
Number of messages printed are 1
print方法中的打印语句并未被执行。这种行为差异表明，Stream管道中的某些中间操作在不同Java版本中可能以不同的方式被评估。
Stream API副作用机制解析
这种行为差异的根源在于Java Stream API对“副作用”的处理原则。Stream API的设计哲学是鼓励无状态、无副作用的函数式操作。官方文档明确指出：
Stream操作的行为参数中的副作用通常不被鼓励，因为它们可能导致无意中违反无状态要求，以及其他线程安全隐患。如果行为参数确实存在副作用，除非明确声明，否则无法保证：这些副作用对其他线程的可见性；同一Stream管道中“相同”元素的不同操作是否在同一线程中执行；行为参数总是被调用，因为Stream实现可以自由地省略Stream管道中的操作（或整个阶段），如果它能证明这不会影响计算结果。
（强调部分为原文加粗）
这意味着，Stream的实现者可以自由地优化管道，跳过那些不影响最终结果的中间操作，即使这些操作包含副作用。尤其对于那些不改变元素数量或不影响最终聚合结果的中间操作，其副作用可能不会被执行。
count()操作的优化原理
count()操作是Stream API中的一个终端操作，用于返回Stream中的元素数量。Java 9及更高版本对count()的实现进行了优化，以提高性能：
实现可以选择不执行Stream管道（无论是顺序还是并行），如果它能够直接从Stream源计算出数量。在这种情况下，不会遍历任何源元素，也不会评估任何中间操作。
Qoder
阿里巴巴推出的AI编程工具
270 查看详情
这意味着，如果Stream的源（例如一个Collection）能够直接提供其大小信息，或者Stream管道中的操作（如filter、map）不改变元素的数量，并且count()能够通过其他方式确定最终的数量，那么Stream实现就有可能跳过整个管道的执行，包括所有的中间操作。
在上述示例中，Stream的源最终是一个包含单个Message对象的Stream。filter操作和map(Collection::stream)操作最终都会导致一个包含单个元素的Stream。当count()被调用时，它可能识别出Stream源（或经过简单转换后的源）能够直接提供元素数量（即1），从而决定不实际遍历元素并执行map(TestingJavaStream::print)这个中间操作。因此，print方法的副作用就不会发生。
peek()操作的类似情况
另一个常用于调试且可能被优化的中间操作是peek()。peek()设计初衷是用于调试，允许在不改变Stream元素的情况下查看它们。然而，其副作用（如打印）也同样不被保证执行，因为它不影响Stream的最终结果。
最佳实践与解决方案
为了编写健壮且行为可预测的Java Stream代码，我们应遵循以下最佳实践：
避免在中间操作中依赖副作用： 这是核心原则。Stream的中间操作应尽可能保持纯净，即它们只接收输入，产生输出，并且不改变外部状态。将副作用限制在终端操作中： 如果确实需要执行副作用，应将其放在明确设计用于副作用的终端操作中，例如forEach()或forEachOrdered()。这些操作保证会遍历Stream中的每个元素并执行其行为参数。理解操作的语义： 在使用Stream API时，仔细阅读每个操作的文档，了解其是否保证执行行为参数，以及是否存在优化导致副作用被跳过的可能性。
示例：如何可靠地打印Stream元素
如果我们的目的是在计数之前打印每个元素，正确的做法是使用forEach终端操作来处理副作用，或者将副作用集成到业务逻辑中，而不是依赖map的副作用：
方法一：使用 forEach 分离副作用
import java.util.*;import java.util.function.Predicate;import java.util.stream.Stream;public class TestingJavaStreamCorrected { public static void main(String[] args) { Message message = new Message(); message.setName("Hello World!"); Stream messageStream = streamNonnulls(Collections.singleton(message)) .filter(not(Collection::isEmpty)) .findFirst() .map(Collection::stream) .orElseGet(Stream::empty); // 先执行副作用，再重新获取Stream进行计数 List messagesToProcess = messageStream.collect(Collectors.toList()); System.out.println("Messages being processed:"); messagesToProcess.stream() .forEach(TestingJavaStreamCorrected::print); // 明确的副作用处理 System.out.println("Number of messages printed are " + messagesToProcess.stream().count()); // 仅计数 } // ... Message, streamNonnulls, stream, not 方法与原示例相同 ... public static class Message { /* ... */ } @SafeVarargs public static Stream streamNonnulls(T... in) { /* ... */ return null;} @SafeVarargs public static Stream stream(T... in) { /* ... */ return null;} public static Predicate not(Predicate p) { /* ... */ return null;} public static Message print(Message someValue) { System.out.println("Message is :: "+someValue.toString()); return someValue; }}
注意事项： 上述示例中，为了在forEach之后还能对Stream进行count，我们先将Stream收集为List。Stream一旦经过终端操作就会被“消费”，不能再次使用。如果业务逻辑允许，也可以直接在forEach中进行计数，但这通常不如count()高效。
方法二：更简洁的重构（如果原意是先打印再计数）
如果目标是先打印，然后获得打印元素的数量，可以这样操作：
import java.util.*;import java.util.function.Predicate;import java.util.stream.Stream;public class TestingJavaStreamRefactored { public static void main(String[] args) { Message message = new Message(); message.setName("Hello World!"); Stream initialStream = streamNonnulls(Collections.singleton(message)) .filter(not(Collection::isEmpty)) .findFirst() .map(Collection::stream) .orElseGet(Stream::empty); // 使用peek进行调试性打印，但仍需注意其不保证执行的特性 // 如果需要保证打印，应使用forEach或先collect long count = initialStream .peek(TestingJavaStreamRefactored::print) // 此时peek的行为取决于JVM优化 .count(); System.out.println("Number of messages counted are " + count); } // ... Message, streamNonnulls, stream, not, print 方法与原示例相同 ... public static class Message { /* ... */ } @SafeVarargs public static Stream streamNonnulls(T... in) { /* ... */ return null;} @SafeVarargs public static Stream stream(T... in) { /* ... */ return null;} public static Predicate not(Predicate p) { /* ... */ return null;} public static Message print(Message someValue) { /* ... */ return null;}}
重要提示： 即使使用peek，其副作用的执行也不被保证。在Java 9+中，上述代码仍可能不会打印。如果必须确保打印，最可靠的方法是先将Stream收集到集合中，然后对集合进行迭代或创建新的Stream。
总结
从Java 8到Java 9，Stream API在优化策略上有所演进，尤其是count()等终端操作的优化可能导致带有副作用的中间操作被跳过。这一变化并非错误，而是Stream API设计原则（避免副作用、鼓励纯函数）的体现。作为开发者，我们应当深入理解Stream API的契约，避免在中间操作中依赖副作用，并始终将副作用操作放置在合适的终端操作中（如forEach），以确保代码在不同Java版本和不同执行环境下都能保持一致且可预测的行为。遵循这些最佳实践，将有助于编写出更健壮、更易于维护的Stream代码。
以上就是Java Stream API中副作用行为的跨版本差异与最佳实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/974946.html
微信扫一扫 
支付宝扫一扫 
