當然，絕對時間上，普通遍歷是快一點，但是…對於程式設計來說，時間複雜度才是衡量的標準吧。除非是特別在意絕對效能的，比如寫在嵌入式機器上之類的，否則……相較於stream內部多建立一些物件，開發效率的提升才是更重要的

本人歷經了Java6～java8的“改朝換代”，說說自己的看法。

首先，不可否認，stream絕對是優雅的代名詞，無論是其序列呼叫方式，還是其api的強大能力，都給予了程式設計師一項特殊技能：高效、簡潔。

但事情並非絕對，但從效能上來說，stream真的比傳統迭代更優嗎？其實不然，還是要依據實際情況來看待問題。

在極少數量的迭代次數下，其實看不出效能效果的差異，固後面所說的幾點都是依賴大量資料迭代的前提之下。

具體分為以下幾點談談：

1、無論什麼程式，都要跑在載體上，而常見的載體就是伺服器，那麼，提到這就很容易聯想到，CPU的處理能力，直接影響到效能問題。

如果只是單核cpu，那麼還是推薦傳統迭代，a）實際測試效果來看，stream效能要明顯差於for迴圈之類的傳統處理方式，尤其在單核cpu時，千萬不要使用stream的併線處理，原因是並行處理時還有另外一項開銷，就是上下文執行緒切換，而此時只有單核cpu，你說這是不是“沒事找事”；

b）當cpu是多核時，並且隨著核數的增加，這時，stream的優勢才能逐漸顯示出來，畢竟並行處理還是由於序列的。

2、事情不是絕對，不是所有情況下，序列處理時stream都不如傳統迭代。比如在複雜物件的處理時（常見的有訂單物件，裡面包含很多資訊），經測試結果發現，stream效能還是由於普通迭代的，那更不用說，在多核cpu下的並行處理了，此處再次強調，不要在單核下使用序列，你會發現效能及其查！

3、最後提一點個人經歷，在使用並行stream時，要謹慎對待迭代處理中進行多外部介面呼叫，可能你會發現並行後因為上下文執行緒切換帶來的開銷反而不一定效能更優於序列，還會給系統穩定性帶來一定影響。

最後總結一下，處於程式碼整潔上考慮，stream還是有明顯優勢的，但是在效能上，大家還是要依據實際情況來做出合理選擇，這樣才能寫出最“優雅”的程式碼。

對於簡單操作，比如最簡單的遍歷，stream序列API效能明顯差於顯示迭代，但並行的stream api能夠發揮多核特性。