## 一、粉絲的反饋  **問：stream比for迴圈慢5倍，用這個是為了啥？** 答：網際網路是一個新聞氾濫的時代，三人成虎，以假亂真的事情時候發生。作為一個技術開發者，要自己去動手去做，不要人云亦云。 的確，這位粉絲說的這篇文章我也看過，我就不貼地址了，也沒必要給他帶流量。怎麼說呢？就是一個不懂得測試的、不入流開發工程師做的效能測試，給出了一個危言聳聽的結論。 ## 二、所有效能測試結論都是片面的 效能測試是必要的，但針對性能測試的結果，永遠要持懷疑態度。為什麼這麼說？ * 效能測試脫離業務場景就是片面的效能測試。你能覆蓋所有的業務場景麼？ * 效能測試脫離硬體環境就是片面的效能測試。你能覆蓋所有的硬體環境麼？ * 效能測試脫離開發人員的知識面就是片面的效能測試。你能覆蓋各種開發人員奇奇怪怪的程式碼麼？ 所以，我從來不相信網上的任何效能測試的文章。凡是我自己的從事的業務場景，我都要在接近生產環境的機器上自己測試一遍。 **所有效能測試結論都是片面的，只有你生產環境下的執行結果才是真的。** ## 三、動手測試Stream的效能 ### 3.1.環境 windows10 、16G記憶體、i7-7700HQ 2.8HZ 、64位作業系統、JDK 1.8.0_171 ### 3.2.測試用例與測試結論 我們在上一節,已經講過： * 針對不同的資料結構，Stream流的執行效率是不一樣的 * 針對不同的資料來源，Stream流的執行效率也是不一樣的 所以記住筆者的話：**所有效能測試結論都是片面的**，你要自己動手做，相信你自己的程式碼和你的環境下的測試！我的測試結果僅僅代表我自己的測試用例和測試資料結構！ #### 3.2.1.測試用例一 測試用例：5億個int隨機數，求最小值 測試結論（測試程式碼見後文）： * 使用普通for迴圈，執行效率是Stream序列流的2倍。也就是說普通for迴圈效能更好。 * Stream並行流計算是普通for迴圈執行效率的4-5倍。 * Stream並行流計算 > 普通for迴圈 > Stream序列流計算  ### 3.2.測試用例二 測試用例：長度為10的1000000隨機字串，求最小值 測試結論（測試程式碼見後文）： * 普通for迴圈執行效率與Stream序列流不相上下 * Stream並行流的執行效率遠高於普通for迴圈 * Stream並行流計算 > 普通for迴圈 = Stream序列流計算  ### 3.3.測試用例三 測試用例：10個使用者，每人200個訂單。按使用者統計訂單的總價。 測試結論（測試程式碼見後文）： * Stream並行流的執行效率遠高於普通for迴圈 * Stream序列流的執行效率大於等於普通for迴圈 * Stream並行流計算 > Stream序列流計算 >= 普通for迴圈  ## 四、最終測試結論 * 對於簡單的數字(list-Int)遍歷，普通for迴圈效率的確比Stream序列流執行效率高（1.5-2.5倍）。但是Stream流可以利用並行執行的方式發揮CPU的多核優勢,因此並行流計算執行效率高於for迴圈。 * 對於list-Object型別的資料遍歷，普通for迴圈和Stream序列流比也沒有任何優勢可言，更不用提Stream並行流計算。 雖然在不同的場景、不同的資料結構、不同的硬體環境下。Stream流與for迴圈效能測試結果差異較大，甚至發生逆轉。**但是總體上而言**： * Stream並行流計算 >> 普通for迴圈 ~= Stream序列流計算 (之所以用兩個大於號，你細品) * 資料容量越大，Stream流的執行效率越高。 * Stream並行流計算通常能夠比較好的利用CPU的多核優勢。CPU核心越多，Stream並行流計算效率越高。 stream比for迴圈慢5倍？也許吧，單核CPU、序列Stream的int型別資料遍歷？我沒試過這種場景，但是我知道這不是應用系統的核心場景。看了十幾篇測試博文，和我的測試結果。我的結論是： **在大多數的核心業務場景下及常用資料結構下，Stream的執行效率比for迴圈更高。** 畢竟我們的業務中通常是實實在在的實體物件，沒事誰總