Java Stream API副作用差异与优化技巧

本文探讨了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环境下执行上述代码，控制台会输出：

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源计算出数量。在这种情况下，不会遍历任何源元素，也不会评估任何中间操作。

这意味着，如果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代码，我们应遵循以下最佳实践：

1. 避免在中间操作中依赖副作用： 这是核心原则。Stream的中间操作应尽可能保持纯净，即它们只接收输入，产生输出，并且不改变外部状态。
2. 将副作用限制在终端操作中： 如果确实需要执行副作用，应将其放在明确设计用于副作用的终端操作中，例如forEach()或forEachOrdered()。这些操作保证会遍历Stream中的每个元素并执行其行为参数。
3. 理解操作的语义： 在使用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代码。