震惊 java一个大坑, 被老板约谈了。
引言
在Java 8中，Stream API引入了许多强大的函数式编程特性，极大地增强了我们对集合数据进行操作的能力。其中一个很有用的方法就是peek()，本文将详细介绍其功能及应用场景。
peek() 方法简介
peek() 是Java 8 Stream API中的一个中间操作方法，它的主要功能是对流中的每个元素执行一个操作（可以是获取、修改或打印等），而不影响流的整体处理流程。这意味着即使使用了peek()，流也可以继续进行后续的映射、过滤或其他操作。
<T> Stream<T> peek(Consumer<? super T> action);参数action是一个Consumer接口的实现，它接受一个泛型参数T，并对其执行某种操作。
示例一：简单使用 peek() 打印元素（）
import java.util.Arrays;import java.util.List;import java.util.stream.Stream;public class PeekExample { public static void main(String[] args) { List<String> addrList = Arrays.asList("AAA"); addrList.stream() .filter(Objects::nonNull) .peek(info -> { System.out.println("Processing Element: " + info); }).collect(Collectors.toList()); // 输出：Processing Element: AAA }}在这个例子中，我们首先创建了一个包含一个元素"AAA"的列表，并将其转换为流。随后使用filter()方法去除可能存在的空元素（在此例中其实无需过滤，因为已知元素不为空）。关键在于peek()方法的应用，它接收一个lambda表达式，每当流中的元素被访问时，就执行该表达式，从而实现了打印当前处理元素的功能。
有坑的点：删除流终止操作，将会不执行。
import java.util.Arrays;import java.util.List;import java.util.stream.Stream;public class PeekExample { public static void main(String[] args) { List<String> addrList = Arrays.asList("AAA"); addrList.stream() .filter(Objects::nonNull) .peek(info -> { System.out.println("Processing Element: " + info); }); // 输出： }}这段代码中peek不会被执行，并且不会打印。
peek()方法是 Strean 接口中的一个中间操作，它允许你在流的每 个元素上执行一个操作，但是这个操作是在最终的终端操作(如
forEach,collect,limit 等)执行 前进行的。 然而，如果 peek()是流中唯一的操作，那么它实际上不会执行。这是因为
peek ()本身并不是一个 终端操作，它不会触发流的执行。在 jav 8 及以后的版本中，流的执行是情性的，这意味着流操作
不会立即执行，而是在遇到终端操作时才会实际执行
示例二：结合 peek() 进行调试
peek()方法的一个常见用途是在调试时查看流中的元素状态，而不会影响到流的最终处理结果。
Stream<Integer> numbers = Stream.of(1, 2, 3, 4, 5);numbers.map(n -> n * 2) // 将每个数乘以2 .peek(n -> System.out.println("Mapped value: " + n)) .filter(n -> n % 3 == 0) // 过滤出能被3整除的数 .peek(n -> System.out.println("Filtered value: " + n)) .collect(Collectors.toList()); // 收集到List中在上述代码中，我们在映射和过滤操作之间插入了两次peek()，分别用来查看映射后的值和过滤后的值，这对于理解流的处理过程非常有帮助。
总结起来，peek()方法就像是一个观察者，可以在不影响流整体处理的情况下，让我们有机会在每个元素上执行一些额外的操作，例如日志记录、临时计算、调试信息打印等。但它并不改变流的原始内容，也不决定流的最终输出结果。要得到流的处理结果，还需要进一步调用诸如collect(), forEach(), reduce()等终端操作方法。
需要注意的坑
坑一：peek() 不影响流的生成和消费
peek()是一个中间操作，它并不会终止流的处理流程，因此如果不跟一个终端操作（如collect(), forEach(), count()等），则peek()中的操作虽然会被执行，但整个流式处理链的结果不会有任何产出。换言之，只有当流被消耗时，peek()里的操作才会真正发生。
坑二：peek() 的执行次数取决于下游操作
peek()方法中的动作会在流的每个元素上执行一次，但具体执行多少次取决于下游的终端操作。例如，如果你在排序(sorted())前使用了peek()，而在排序后又使用了一次peek()，则同一个元素可能会被两次peek()。
坑三：并发流中的peek()行为
对于并行流，peek()操作的执行顺序没有保证，而且可能会多次执行（取决于JVM的具体调度）。如果你在并行流中依赖peek()的顺序性或唯一性，可能会遇到意想不到的问题。
坑四：资源管理
如果在peek()中打开了一些资源（如文件、数据库连接等），但在peek()内部并未妥善关闭它们，可能会导致资源泄露。因为在没有终端操作的情况下，流可能不会立即执行，资源也就无法及时释放。
坑五：对流元素的修改可能无效
peek()通常用于读取或打印流元素，而不是修改它们。虽然理论上可以尝试在peek()中修改元素，但由于流的惰性求值和可能的不可变性，这样的修改可能不会反映到源集合或后续流操作中。
