簡介

自從JDK中引入了stream之後，彷彿一切都變得很簡單，根據stream提供的各種方法，如map，peek，flatmap等等，讓我們的編程變得更美好。

事實上，我也經常在項目中看到有些小夥伴會經常使用peek來進行一些業務邏輯處理。

那麼既然JDK文檔中説peek方法主要是在調試的情況下使用，那麼peek一定存在着某些不為人知的缺點。一起來看看吧。

peek的定義和基本使用

先來看看peek的定義：

    Stream<T> peek(Consumer<? super T> action);

peek方法接受一個Consumer參數，返回一個Stream結果。

而Consumer是一個FunctionalInterface，它需要實現的方法是下面這個：

    void accept(T t);

accept對傳入的參數T進行處理，但是並不返回任何結果。

我們先來看下peek的基本使用：

    public static void peekOne(){
        Stream.of(1, 2, 3)
                .peek(e -> log.info(String.valueOf(e)))
                .toList();
    }

運行上面的代碼，我們可以得到：

[main] INFO com.flydean.Main - 1
[main] INFO com.flydean.Main - 2
[main] INFO com.flydean.Main - 3

邏輯很簡單，就是打印出Stream中的元素而已。

peek的流式處理

peek作為stream的一個方法，當然是流式處理的。接下來我們用一個具體的例子來説明流式處理具體是如何操作的。

    public static void peekForEach(){
        Stream.of(1, 2, 3)
                .peek(e -> log.info(String.valueOf(e)))
                .forEach(e->log.info("forEach"+e));
    }

這一次我們把toList方法替換成了forEach，通過具體的打印日誌來看看到底發生了什麼。

[main] INFO com.flydean.Main - 1
[main] INFO com.flydean.Main - forEach1
[main] INFO com.flydean.Main - 2
[main] INFO com.flydean.Main - forEach2
[main] INFO com.flydean.Main - 3
[main] INFO com.flydean.Main - forEach3

通過日誌，我們可以看出，流式處理的流程是對應流中的每一個元素，分別經歷了peek和forEach操作。而不是先把所有的元素都peek過後再進行forEach。

Stream的懶執行策略

之所有會有流式操作，就是因為可能要處理的數據比較多，無法一次性加載到內存中。

所以為了優化stream的鏈式調用的效率，stream提供了一個懶加載的策略。

什麼是懶加載呢？

就是説stream的方法中，除了部分terminal operation之外，其他的都是intermediate operation.

比如count，toList這些就是terminal operation。當接受到這些方法的時候，整個stream鏈條就要執行了。

而peek和map這些操作就是intermediate operation。

intermediate operation的特點是立即返回，如果最後沒有以terminal operation結束,intermediate operation實際上是不會執行的。

我們來看個具體的例子：

    public static void peekLazy(){
        Stream.of(1, 2, 3)
                .peek(e -> log.info(String.valueOf(e)));
    }

運行之後你會發現，什麼輸出都沒有。

這表示peek中的邏輯並沒有被調用，所以這種情況大家一定要注意。

peek為什麼只被推薦在debug中使用

如果你閲讀過peek的文檔，你可能會發現peek是隻被推薦在debug中使用的，為什麼呢？

JDK中的原話是這樣説的：

In cases where the stream implementation is able to optimize away the production of some or all the elements (such as with short-circuiting operations like findFirst, or in the example described in count), the action will not be invoked for those elements.

翻譯過來的意思就是，因為stream的不同實現對實現方式進行了優化，所以不能夠保證peek中的邏輯一定會被調用。

我們再來舉個例子：

    public static void peekNotExecute(){
        Stream.of(1, 2, 3)
                .peek(e -> log.info("peekNotExecute"+e))
                .count();
    }

這裏的terminal operation是count，表示對stream中的元素進行統計。

因為peek方法中參數是一個Consumer，它不會對stream中元素的個數產生影響，所以最後的運行結果就是3。

peek中的日誌輸出並沒有打印出來，表示peek沒有被執行。

所以，我們在使用peek的時候，一定要注意peek方法是否會被優化。要不然就會成為一個隱藏很深的bug。

peek和map的區別

好了，講到這裏，大家應該對peek有了一個全面的認識了。但是stream中還有一個和peek類似的方法叫做map。他們有什麼區別呢？

前面我們講到了peek方法需要的參數是Consumer，而map方法需要的參數是一個Function:

    <R> Stream<R> map(Function<? super T, ? extends R> mapper);

Function也是一個FunctionalInterface,這個接口需要實現下面的方法：

    R apply(T t);

可以看出apply方法實際上是有返回值的，這跟Consumer是不同的。所以一般來説map是用來修改stream中具體元素的。 而peek則沒有這個功能。

peek方法接收一個Consumer的入參. 瞭解λ表達式的應該明白 Consumer的實現類應該只有一個方法，該方法返回類型為void. 它只是對Stream中的元素進行某些操作,但是操作之後的數據並不返回到Stream中,所以Stream中的元素還是原來的元素.

map方法接收一個Function作為入參. Function是有返回值的, 這就表示map對Stream中的元素的操作結果都會返回到Stream中去.

• 要注意的是，peek對一個對象進行操作的時候,雖然對象不變,但是可以改變對象裏面的值。

大家可以運行下面的例子：

    public static void peekUnModified(){
        Stream.of(1, 2, 3)
                .peek(e -> e=e+1)
                .forEach(e->log.info("peek unModified"+e));
    }

    public static void mapModified(){
        Stream.of(1, 2, 3)
                .map(e -> e=e+1)
                .forEach(e->log.info("map modified"+e));
    }

總結

以上就是對peek的總結啦，大家在使用的時候一定要注意存在的諸多陷阱。

本文的例子https://github.com/ddean2009/learn-java-base-9-to-20/tree/master/peek-and-map/

更多文章請看 www.flydean.com