Java 8提供的流的基于Lambda表達式的函數式的操作寫法讓人感覺很爽，筆者也一直用的很開心，直到看到了Java8 Lambda表達式和流操作如何讓你的代碼變慢5倍，筆者當時是震驚的，我讀書少，你不要騙我。瞬間我似乎為我的Server Application速度慢找到了一個很好地鍋，不過這個跟書上講的不一樣啊。于是筆者追本溯源，最后找到了始作俑者自己的分析：原文
不久之前我在社區內發表了這篇文章：?I mused about the performance of Java 8 streams?，上面的測試結果貌似很有道理。其中一個測試是將傳統的for-循環與Stream進行了比較。很多人表示了震驚、不相信等等很多很多的情緒，甚至有人直接說Stream是個什么鬼，哪涼快哪呆著去。這是沒有道理的，畢竟不能通過一個簡單地只是一個環境下的測試就否定這些。
在之前的測評中，在500,000個隨機的整形數的數組的遍歷中，我們得出的結論是for-循環的速度會比Stream的速度快上15倍。其中for-循環的數組如下所示：
int[] a = ints;
int e = ints.length;
int m = Integer.MIN_VALUE;for (int i = 0; i < e; i++)if (a[i] > m) m = a[i];同樣的，我們建立了一個原始類型的IntStream：
int m = Arrays.stream(ints).reduce(Integer.MIN_VALUE, Math::max);在我們這個過時的設備上（雙核）跑出來的結果是：
int-array, for-loop : 0.36 ms
int-array, seq. stream: 5.35 msfor循環的方式明顯的比Stream流要快很多很多，然后我們選擇了另一臺4核的設備，發現這個比例因子變成了4.2(原來是15)。這個結果的詳細信息可以看Nicolai Parlog’s blog?這個文章：
正如我們所料，不同的環境可能會引發不同的結果。不過我們評測的核心：for-循環速度奏是比Stream快，在不同的平臺上是一致的。
接下來，我們不再測試原始類型，改用了ArrayList<Integer>,同樣是填充了500000個隨機數，然后結果是：
ArrayList, for-loop : 6.55 ms
ArrayList, seq. stream: 8.33 ms是的，for-循環的速度確實還是會快一點，但是很明顯這種差距縮小了。這個結果并不令人驚訝，實際上整個測試的性能主要取決于內存訪問與遍歷這兩大塊。其中內存訪問這個還受限制于硬件本身，所以不同的平臺上會有不同的結果。實際上在我們的測試中出現這樣的結果并不會令人驚訝，畢竟我們特意選擇了一個比較極端的情況，代表了范圍內的某個極端，可以解釋如下：
我們將
for-loops與Streams進行了比較。循環本身是JIT友好的。編譯器本身有了40年以上的經驗，然后我們選擇了循環這個JIT編譯器重點優化的部分。這是所謂的某個極端：一個JIT友好的，高度優化的訪問序列元素的方法。而如果是使用流的話也就意味著會在主框架內進行調用，不可避免地增加內存調用。而一個JIT編譯器本身是有一個上限的，雖然大部分情況下是用不滿的。因此，我們將這種情況分為JIT友好與不友好，而for-循環本身是處于JIT友好的這一邊，因此它自然能夠贏得這個測試，并沒有神馬奇怪。我們將原始類型的序列與引用類型的序列進行了比較。這兩種情況可以用緩存友好/不友好來區分。一個原始類型int的序列是非常緩存友好的，特別是當未來Java引入不可變序列的時候。而一個引用類型的序列，即使用了基于數組的，就像ArrayList的這樣的存儲，也是只有很小的概率進行很好地緩存。每次獨立地對于序列成員的訪問需要獲取指針指向的地址然后獲取其內容，也就意味著緩存的失效。很明顯地，一個使用了
int[]的for-循環肯定處在緩存友好這一邊，自然與序列引用的Stream相比性能上要好上很多。我們將元素輕量級使用與CPU密集型使用相比。更重要的是，我們將這種兩個兩個的比較尋找最大值的計算與Taylor相似度下尋找正弦值的計算進行了比較。在下面一個實驗中，我們會以相對而言復雜一點的CPU密集型的運算為例，可能獲取到這個值需要一分鐘的時間。我們將此稱作CPU友好或者CPU不友好的分割。一般來說，對于序列中的元素進行重量級的CPU密集型的運算的時候，也就是所謂的CPU不友好運算時，評測結果往往由CPU的運算速度決定，而對于上面講的緩存缺失以及JIT循環的優化就變得不那么重要了。
講了這么多，我們已經可以發現上面評測中對于int[]類型的數組中尋找最大值的這件事是受到JIT友好以及緩存友好這兩個因素決定的。這種情況下，當然for-循環會占了很大優勢，如果沒做到這樣才會讓人驚訝呢。那么如果我們對于上文中所講的CPU密集型的情況，這也是一種極端情況，進行評測，其中for-循環式這樣的：
int[] a = ints;
int e = a.length;
double m = Double.MIN_VALUE;for (int i = 0; i < e; i++) {double d = Sine.slowSin(a[i]);if (d > m) m = d;
}Stream的用法如下：
Arrays.stream(ints).mapToDouble(Sine::slowSin).reduce(Double.MIN_VALUE, (i, j) -> Math.max(i, j));最后的結果是：
for``-loop?? : ``11.82` `ms
seq. stream: ``12.15` `ms這個評測依舊是在上文說到的那個老舊的機器上進行的。確實for-循環的效率是比Stream要快的，不過可以看得出來這種差距不再明顯了。換種說法，這種差距在統計評測的角度來看還是很重要的，不過在實際的應用過程中已經無足輕重了。到這里我們證明了與上次評測相悖的一個觀點：其實Stream與for-循環之間的性能并木有很大的差異。
最后來總結一波，在有些情況下，Stream的效率確實會比for-循環要慢上很多倍，然后在其他大部分情況下是沒有蝦米差異的。你可以覺得Stream很酷然后就去使用它，或者為了優化你的應用的性能而依舊選擇舊的語法。同時，也不要無緣無故就覺得人家Stream損害了你應用的性能，那是你自己用得不好。
