Stream流水線的實現(xiàn)原理是什么

這篇文章主要介紹“Stream流水線的實現(xiàn)原理是什么”，在日常操作中，相信很多人在Stream流水線的實現(xiàn)原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Stream流水線的實現(xiàn)原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

前面我們已經(jīng)學(xué)會如何使用Stream API

• Lambda表達(dá)式和函數(shù)接口的關(guān)系。

• Java集合框架（Collections）新加入的方法

• Stream API基本用法

• Stream規(guī)約操作用法

用起來真的很爽，但簡潔的方法下面似乎隱藏著無盡的秘密，如此強大的API是如何實現(xiàn)的呢？比如Pipeline是怎么執(zhí)行的，每次方法調(diào)用都會導(dǎo)致一次迭代嗎？自動并行又是怎么做到的，線程個數(shù)是多少？本節(jié)我們學(xué)習(xí)Stream流水線的原理，這是Stream實現(xiàn)的關(guān)鍵所在。

首先回顧一下容器執(zhí)行Lambda表達(dá)式的方式，以ArrayList.forEach()方法為例，具體代碼如下：

我們看到ArrayList.forEach()方法的主要邏輯就是一個for循環(huán)，在該for循環(huán)里不斷調(diào)用action.accept()回調(diào)方法完成對元素的遍歷。這完全沒有什么新奇之處，回調(diào)方法在Java GUI的監(jiān)聽器中廣泛使用。Lambda表達(dá)式的作用就是相當(dāng)于一個回調(diào)方法，這很好理解。?

Stream API中大量使用Lambda表達(dá)式作為回調(diào)方法，但這并不是關(guān)鍵。理解Stream我們更關(guān)心的是另外兩個問題：流水線和自動并行。使用Stream或許很容易寫入如下形式的代碼：

上述代碼求出以字母A開頭的字符串的最大長度，一種直白的方式是為每一次函數(shù)調(diào)用都執(zhí)一次迭代，這樣做能夠?qū)崿F(xiàn)功能，但效率上肯定是無法接受的。類庫的實現(xiàn)著使用流水線（Pipeline）的方式巧妙的避免了多次迭代，其基本思想是在一次迭代中盡可能多的執(zhí)行用戶指定的操作。為講解方便我們匯總了Stream的所有操作。

Stream上的所有操作分為兩類：中間操作和結(jié)束操作，中間操作只是一種標(biāo)記，只有結(jié)束操作才會觸發(fā)實際計算。中間操作又可以分為無狀態(tài)的(Stateless)和有狀態(tài)的(Stateful)，無狀態(tài)中間操作是指元素的處理不受前面元素的影響，而有狀態(tài)的中間操作必須等到所有元素處理之后才知道最終結(jié)果，比如排序是有狀態(tài)操作，在讀取所有元素之前并不能確定排序結(jié)果；結(jié)束操作又可以分為短路操作和非短路操作，短路操作是指不用處理全部元素就可以返回結(jié)果，比如找到第一個滿足條件的元素。之所以要進(jìn)行如此精細(xì)的劃分，是因為底層對每一種情況的處理方式不同。為了更好的理解流的中間操作和終端操作，可以通過下面的兩段代碼來看他們的執(zhí)行過程。

image.png

輸出為：A1B1C1 A2B2C2 A3B3C3 中間操作是懶惰的，也就是中間操作不會對數(shù)據(jù)做任何操作，直到遇到了最終操作。而最終操作，都是比較熱情的。他們會往前回溯所有的中間操作。也就是當(dāng)執(zhí)行到最后的forEach操作的時候，它會回溯到它的上一步中間操作，上一步中間操作，又會回溯到上上一步的中間操作，...，直到最初的第一步。第一次forEach執(zhí)行的時候，會回溯peek 操作，然后peek會回溯更上一步的limit操作，然后limit會回溯更上一步的peek操作，頂層沒有操作了，開始自上向下開始執(zhí)行，輸出：A1B1C1 第二次forEach執(zhí)行的時候，然后會回溯peek 操作，然后peek會回溯更上一步的limit操作，然后limit會回溯更上一步的peek操作，頂層沒有操作了，開始自上向下開始執(zhí)行，輸出：A2B2C2

... 當(dāng)?shù)谒拇蝔orEach執(zhí)行的時候，然后會回溯peek 操作，然后peek會回溯更上一步的limit操作，到limit的時候，發(fā)現(xiàn)limit(3)這個job已經(jīng)完成，這里就相當(dāng)于循環(huán)里面的break操作，跳出來終止循環(huán)。

再來看第二段代碼：

image.png

輸出為：A1 A2 A3 A4 A5 A6 A7B7C7 A8B8C8 A9B9C9 第一次forEach執(zhí)行的時候，會回溯peek操作，然后peek會回溯更上一步的skip操作，skip回溯到上一步的peek操作，頂層沒有操作了，開始自上向下開始執(zhí)行，執(zhí)行到skip的時候，因為執(zhí)行到skip，這個操作的意思就是跳過，下面的都不要執(zhí)行了，也就是就相當(dāng)于循環(huán)里面的continue，結(jié)束本次循環(huán)。輸出：A1

第二次forEach執(zhí)行的時候，會回溯peek操作，然后peek會回溯更上一步的skip操作，skip回溯到上一步的peek操作，頂層沒有操作了，開始自上向下開始執(zhí)行，執(zhí)行到skip的時候，發(fā)現(xiàn)這是第二次skip，結(jié)束本次循環(huán)。輸出：A2

...

第七次forEach執(zhí)行的時候，會回溯peek操作，然后peek會回溯更上一步的skip操作，skip回溯到上一步的peek操作，頂層沒有操作了，開始自上向下開始執(zhí)行，執(zhí)行到skip的時候，發(fā)現(xiàn)這是第七次skip，已經(jīng)大于6了，它已經(jīng)執(zhí)行完了skip(6)的job了。這次skip就直接跳過，繼續(xù)執(zhí)行下面的操作。輸出：A7B7C7

...直到循環(huán)結(jié)束。

一種直白的實現(xiàn)方式

仍然考慮上述求最長字符串的程序，一種直白的流水線實現(xiàn)方式是為每一次函數(shù)調(diào)用都執(zhí)一次迭代，并將處理中間結(jié)果放到某種數(shù)據(jù)結(jié)構(gòu)中（比如數(shù)組，容器等）。具體說來，就是調(diào)用filter()方法后立即執(zhí)行，選出所有以A開頭的字符串并放到一個列表list1中，之后讓list1傳遞給mapToInt()方法并立即執(zhí)行，生成的結(jié)果放到list2中，最后遍歷list2找出最大的數(shù)字作為最終結(jié)果。程序的執(zhí)行流程如如所示：

這樣做實現(xiàn)起來非常簡單直觀，但有兩個明顯的弊端：

1. 迭代次數(shù)多。迭代次數(shù)跟函數(shù)調(diào)用的次數(shù)相等。

2. 頻繁產(chǎn)生中間結(jié)果。每次函數(shù)調(diào)用都產(chǎn)生一次中間結(jié)果，存儲開銷無法接受。

這些弊端使得效率底下，根本無法接受。如果不使用Stream API我們都知道上述代碼該如何在一次迭代中完成，大致是如下形式：

image.png

采用這種方式我們不但減少了迭代次數(shù)，也避免了存儲中間結(jié)果，顯然這就是流水線，因為我們把三個操作放在了一次迭代當(dāng)中。只要我們事先知道用戶意圖，總是能夠采用上述方式實現(xiàn)跟Stream API等價的功能，但問題是Stream類庫的設(shè)計者并不知道用戶的意圖是什么。如何在無法假設(shè)用戶行為的前提下實現(xiàn)流水線，是類庫的設(shè)計者要考慮的問題。

Stream流水線解決方案

我們大致能夠想到，應(yīng)該采用某種方式記錄用戶每一步的操作，當(dāng)用戶調(diào)用結(jié)束操作時將之前記錄的操作疊加到一起在一次迭代中全部執(zhí)行掉。沿著這個思路，有幾個問題需要解決：

1. 用戶的操作如何記錄？

2. 操作如何疊加？

3. 疊加之后的操作如何執(zhí)行？（后續(xù)專門針對問題點分析）

4. 執(zhí)行后的結(jié)果（如果有）在哪里？（后續(xù)專門針對問題點分析）

操作如何記錄

注意這里使用的是“操作(operation)”一詞，指的是“Stream中間操作”的操作，很多Stream操作會需要一個回調(diào)函數(shù)（Lambda表達(dá)式），因此一個完整的操作是<數(shù)據(jù)來源，操作，回調(diào)函數(shù)>構(gòu)成的三元組。Stream中使用Stage的概念來描述一個完整的操作，并用某種實例化后的PipelineHelper來代表Stage，將具有先后順序的各個Stage連到一起，就構(gòu)成了整個流水線。跟Stream相關(guān)類和接口的繼承關(guān)系圖示。

還有IntPipeline, LongPipeline, DoublePipeline沒在圖中畫出，這三個類專門為三種基本類型（不是包裝類型）而定制的，跟ReferencePipeline是并列關(guān)系。圖中Head用于表示第一個Stage，即調(diào)用調(diào)用諸如Collection.stream()方法產(chǎn)生的Stage，很顯然這個Stage里不包含任何操作；StatelessOp和StatefulOp分別表示無狀態(tài)和有狀態(tài)的Stage，對應(yīng)于無狀態(tài)和有狀態(tài)的中間操作。

Stream流水線組織結(jié)構(gòu)示意圖如下：

圖中通過Collection.stream()方法得到Head也就是stage0，緊接著調(diào)用一系列的中間操作，不斷產(chǎn)生新的Stream。這些Stream對象以雙向鏈表的形式組織在一起，構(gòu)成整個流水線，由于每個Stage都記錄了前一個Stage和本次的操作以及回調(diào)函數(shù)，依靠這種結(jié)構(gòu)就能建立起對數(shù)據(jù)源的所有操作。這就是Stream記錄操作的方式。

操作如何疊加

以上只是解決了操作記錄的問題，要想讓流水線起到應(yīng)有的作用我們需要一種將所有操作疊加到一起的方案。你可能會覺得這很簡單，只需要從流水線的head開始依次執(zhí)行每一步的操作（包括回調(diào)函數(shù)）就行了。這聽起來似乎是可行的，但是你忽略了前面的Stage并不知道后面Stage到底執(zhí)行了哪種操作，以及回調(diào)函數(shù)是哪種形式。換句話說，只有當(dāng)前Stage本身才知道該如何執(zhí)行自己包含的動作。這就需要有某種協(xié)議來協(xié)調(diào)相鄰Stage之間的調(diào)用關(guān)系。

這種協(xié)議由Sink接口完成，Sink接口包含的方法如下表所示：

有了上面的協(xié)議，相鄰Stage之間調(diào)用就很方便了，每個Stage都會將自己的操作封裝到一個Sink里，前一個Stage只需調(diào)用后一個Stage的accept()方法即可，并不需要知道其內(nèi)部是如何處理的。當(dāng)然對于有狀態(tài)的操作，Sink的begin()和end()方法也是必須實現(xiàn)的。比如Stream.sorted()是一個有狀態(tài)的中間操作，其對應(yīng)的Sink.begin()方法可能創(chuàng)建一個盛放結(jié)果的容器，而accept()方法負(fù)責(zé)將元素添加到該容器，最后end()負(fù)責(zé)對容器進(jìn)行排序。對于短路操作，Sink.cancellationRequested()也是必須實現(xiàn)的，比如Stream.findFirst()是短路操作，只要找到一個元素，cancellationRequested()就應(yīng)該返回true，以便調(diào)用者盡快結(jié)束查找。Sink的四個接口方法常常相互協(xié)作，共同完成計算任務(wù)。實際上Stream API內(nèi)部實現(xiàn)的的本質(zhì)，就是如何重寫Sink的這四個接口方法。

有了Sink對操作的包裝，Stage之間的調(diào)用問題就解決了，執(zhí)行時只需要從流水線的head開始對數(shù)據(jù)源依次調(diào)用每個Stage對應(yīng)的Sink.{begin(), accept(), cancellationRequested(), end()}方法就可以了。一種可能的Sink.accept()方法流程是這樣的：

Sink接口的其他幾個方法也是按照這種[處理->轉(zhuǎn)發(fā)]的模型實現(xiàn)。下面我們結(jié)合具體例子看看Stream的中間操作是如何將自身的操作包裝成Sink以及Sink是如何將處理結(jié)果轉(zhuǎn)發(fā)給下一個Sink的。先看Stream.map()方法：

上述代碼看似復(fù)雜，其實邏輯很簡單，就是將回調(diào)函數(shù)mapper包裝到一個Sink當(dāng)中。由于Stream.map()是一個無狀態(tài)的中間操作，所以map()方法返回了一個StatelessOp內(nèi)部類對象（一個新的Stream），調(diào)用這個新Stream的opWripSink()方法將得到一個包裝了當(dāng)前回調(diào)函數(shù)的Sink。

再來看一個復(fù)雜一點的例子。Stream.sorted()方法將對Stream中的元素進(jìn)行排序，顯然這是一個有狀態(tài)的中間操作，因為讀取所有元素之前是沒法得到最終順序的。拋開模板代碼直接進(jìn)入問題本質(zhì)，sorted()方法是如何將操作封裝成Sink的呢？sorted()一種可能封裝的Sink代碼如下：

上述代碼完美的展現(xiàn)了Sink的四個接口方法是如何協(xié)同工作的：

1. 首先begin()方法告訴Sink參與排序的元素個數(shù)，方便確定中間結(jié)果容器的的大??；

2. 之后通過accept()方法將元素添加到中間結(jié)果當(dāng)中，最終執(zhí)行時調(diào)用者會不斷調(diào)用該方法，直到遍歷所有元素；

3. 最后end()方法告訴Sink所有元素遍歷完畢，啟動排序步驟，排序完成后將結(jié)果傳遞給下游的Sink；

4. 如果下游的Sink是短路操作，將結(jié)果傳遞給下游時不斷詢問下游cancellationRequested()是否可以結(jié)束處理。

總結(jié)

本文詳細(xì)介紹了Stream流水線的組織方式，后續(xù)會持續(xù)針對Stream流水線的執(zhí)行過程進(jìn)行詳細(xì)介紹。學(xué)習(xí)本文將有助于理解原理并寫出正確的Stream代碼，同時打消你對Stream API效率方面的顧慮。如你所見，Stream API實現(xiàn)如此巧妙，即使我們使用外部迭代手動編寫等價代碼，也未必更加高效。

到此，關(guān)于“Stream流水線的實現(xiàn)原理是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>