自從JDK中引入了stream之後，彷彿一切都變得很簡單，根據stream提供的各種方法，如map，peek，flatmap等等，讓我們的程式設計變得更美好。
事實上，我也經常在專案中看到有些小夥伴會經常使用peek來進行一些業務邏輯處理。
那麼既然JDK檔案中說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作為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的方法中，除了部分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的檔案，你可能會發現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有了一個全面的認識了。但是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中去.
大家可以執行下面的例子：
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/