簡介

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

事實上，我也經(jīng)常在項目中看到有些小伙伴會經(jīng)常使用peek來進(jìn)行一些業(yè)務(wù)邏輯處理。

那么既然JDK文檔中說peek方法主要是在調(diào)試的情況下使用，那么peek一定存在著某些不為人知的缺點。一起來看看吧。

peek的定義和基本使用

先來看看peek的定義：

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

peek方法接受一個Consumer參數(shù)，返回一個Stream結(jié)果。

而Consumer是一個FunctionalInterface，它需要實現(xiàn)的方法是下面這個：

    void accept(T t);

accept對傳入的參數(shù)T進(jìn)行處理，但是并不返回任何結(jié)果。

我們先來看下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的一個方法，當(dāng)然是流式處理的。接下來我們用一個具體的例子來說明流式處理具體是如何操作的。

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

這一次我們把toList方法替換成了forEach，通過具體的打印日志來看看到底發(fā)生了什么。

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

通過日志，我們可以看出，流式處理的流程是對應(yīng)流中的每一個元素，分別經(jīng)歷了peek和forEach操作。而不是先把所有的元素都peek過后再進(jìn)行forEach。

Stream的懶執(zhí)行策略

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

所以為了優(yōu)化stream的鏈?zhǔn)秸{(diào)用的效率，stream提供了一個懶加載的策略。

什么是懶加載呢？

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

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

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

intermediate operation的特點是立即返回，如果最后沒有以terminal operation結(jié)束,intermediate operation實際上是不會執(zhí)行的。

我們來看個具體的例子：

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

運行之后你會發(fā)現(xiàn)，什么輸出都沒有。

這表示peek中的邏輯并沒有被調(diào)用，所以這種情況大家一定要注意。

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

如果你閱讀過peek的文檔，你可能會發(fā)現(xiàn)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的不同實現(xiàn)對實現(xiàn)方式進(jìn)行了優(yōu)化，所以不能夠保證peek中的邏輯一定會被調(diào)用。

我們再來舉個例子：

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

這里的terminal operation是count，表示對stream中的元素進(jìn)行統(tǒng)計。

因為peek方法中參數(shù)是一個Consumer，它不會對stream中元素的個數(shù)產(chǎn)生影響，所以最后的運行結(jié)果就是3。

peek中的日志輸出并沒有打印出來，表示peek沒有被執(zhí)行。

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

peek和map的區(qū)別

好了，講到這里，大家應(yīng)該對peek有了一個全面的認(rèn)識了。但是stream中還有一個和peek類似的方法叫做map。他們有什么區(qū)別呢？

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

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

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

    R apply(T t);

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

peek方法接收一個Consumer的入?yún)? 了解λ表達(dá)式的應(yīng)該明白 Consumer的實現(xiàn)類應(yīng)該只有一個方法，該方法返回類型為void. 它只是對Stream中的元素進(jìn)行某些操作,但是操作之后的數(shù)據(jù)并不返回到Stream中,所以Stream中的元素還是原來的元素.

map方法接收一個Function作為入?yún)? Function是有返回值的, 這就表示map對Stream中的元素的操作結(jié)果都會返回到Stream中去.

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

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

    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));
    }

總結(jié)

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

本文的例子github.com/ddean2009/l…

以上就是stream中使用peek一些陷阱避免及解決方法的詳細(xì)內(nèi)容，更多關(guān)于stream使用peek陷阱的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論