建站
咨詢
售后
建站咨詢
新聞中心
這篇文章主要講解了“Java8的Stream API性能分析”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Java8的Stream API性能分析”吧！
站在用戶的角度思考問題，與客戶深入溝通，找到江都網(wǎng)站設(shè)計(jì)與江都網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、外貿(mào)營銷網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋江都地區(qū)。
Stream Performance
已經(jīng)對 Stream API 的用法鼓吹夠多了，用起簡潔直觀，但性能到底怎么樣呢？會不會有很高的性能損失？本節(jié)我們對 Stream API 的性能一探究竟。
為保證測試結(jié)果真實(shí)可信，我們將 JVM 運(yùn)行在 -server模式下，測試數(shù)據(jù)在 GB 量級，測試機(jī)器采用常見的商用服務(wù)器，配置如下：
| OS | CentOS 6.7 x86_64 |
| CPU | Intel Xeon X5675, 12M Cache 3.06 GHz, 6 Cores 12 Threads |
| 內(nèi)存 | 96GB |
| JDK | java version 1.8.0_91, Java HotSpot(TM) 64-Bit Server VM |
測試方法和測試數(shù)據(jù)
性能測試并不是容易的事，Java 性能測試更費(fèi)勁，因?yàn)樘摂M機(jī)對性能的影響很大，JVM 對性能的影響有兩方面：
GC 的影響。GC 的行為是 Java 中很不好控制的一塊，為增加確定性，我們手動指定使用 CMS 收集器，并使用 10GB 固定大小的堆內(nèi)存。具體到 JVM 參數(shù)就是
-XX:+UseConcMarkSweepGC-Xms10G-Xmx10GJIT(Just-In-Time) 即時編譯技術(shù)。即時編譯技術(shù)會將熱點(diǎn)代碼在 JVM 運(yùn)行的過程中編譯成本地代碼，測試時我們會先對程序預(yù)熱，觸發(fā)對測試函數(shù)的即時編譯。相關(guān)的 JVM 參數(shù)是
-XX:CompileThreshold=10000。
Stream 并行執(zhí)行時用到 ForkJoinPool.commonPool()得到的線程池，為控制并行度我們使用 Linux 的 taskset命令指定 JVM 可用的核數(shù)。
測試數(shù)據(jù)由程序隨機(jī)生成。為防止一次測試帶來的抖動，測試 4 次求出平均時間作為運(yùn)行時間。
實(shí)驗(yàn)一 基本類型迭代
測試內(nèi)容：找出整型數(shù)組中的最小值。對比 for 循環(huán)外部迭代和 Stream API 內(nèi)部迭代性能。
測試程序 IntTest，測試結(jié)果如下圖：
圖中展示的是 for 循環(huán)外部迭代耗時為基準(zhǔn)的時間比值。分析如下：
對于基本類型 Stream 串行迭代的性能開銷明顯高于外部迭代開銷（兩倍）；
Stream 并行迭代的性能比串行迭代和外部迭代都好。
并行迭代性能跟可利用的核數(shù)有關(guān)，上圖中的并行迭代使用了全部 12 個核，為考察使用核數(shù)對性能的影響，我們專門測試了不同核數(shù)下的 Stream 并行迭代效果：
分析，對于基本類型：
使用 Stream 并行 API 在單核情況下性能很差，比 Stream 串行 API 的性能還差；
隨著使用核數(shù)的增加，Stream 并行效果逐漸變好，比使用 for 循環(huán)外部迭代的性能還好。
以上兩個測試說明，對于基本類型的簡單迭代，Stream 串行迭代性能更差，但多核情況下 Stream 迭代時性能較好。
實(shí)驗(yàn)二 對象迭代
再來看對象的迭代效果。
測試內(nèi)容：找出字符串列表中最小的元素（自然順序），對比 for 循環(huán)外部迭代和 Stream API 內(nèi)部迭代性能。
測試程序 StringTest，測試結(jié)果如下圖：
結(jié)果分析如下：
對于對象類型 Stream 串行迭代的性能開銷仍然高于外部迭代開銷（1.5 倍），但差距沒有基本類型那么大。
Stream 并行迭代的性能比串行迭代和外部迭代都好。
再來單獨(dú)考察 Stream 并行迭代效果：
分析，對于對象類型：
使用 Stream 并行 API 在單核情況下性能比 for 循環(huán)外部迭代差；
隨著使用核數(shù)的增加，Stream 并行效果逐漸變好，多核帶來的效果明顯。
以上兩個測試說明，對于對象類型的簡單迭代，Stream 串行迭代性能更差，但多核情況下 Stream 迭代時性能較好。
實(shí)驗(yàn)三 復(fù)雜對象歸約
從實(shí)驗(yàn)一、二的結(jié)果來看，Stream 串行執(zhí)行的效果都比外部迭代差（很多），是不是說明 Stream 真的不行了？先別下結(jié)論，我們再來考察一下更復(fù)雜的操作。
測試內(nèi)容：給定訂單列表，統(tǒng)計(jì)每個用戶的總交易額。對比使用外部迭代手動實(shí)現(xiàn)和 Stream API 之間的性能。
我們將訂單簡化為 Order對象來表示。測試程序 ReductionTest，測試結(jié)果如下圖：
分析，對于復(fù)雜的歸約操作：
Stream API 的性能普遍好于外部手動迭代，并行 Stream 效果更佳；
再來考察并行度對并行效果的影響，測試結(jié)果如下：
分析，對于復(fù)雜的歸約操作：
使用 Stream 并行歸約在單核情況下性能比串行歸約以及手動歸約都要差，簡單說就是最差的；
隨著使用核數(shù)的增加，Stream 并行效果逐漸變好，多核帶來的效果明顯。
以上兩個實(shí)驗(yàn)說明，對于復(fù)雜的歸約操作，Stream 串行歸約效果好于手動歸約，在多核情況下，并行歸約效果更佳。我們有理由相信，對于其他復(fù)雜的操作，Stream API 也能表現(xiàn)出相似的性能表現(xiàn)。
感謝各位的閱讀，以上就是“Java8的Stream API性能分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Java8的Stream API性能分析這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！
網(wǎng)站欄目：Java8的StreamAPI性能分析
網(wǎng)頁鏈接：http://www.dlmjj.cn/article/pjoohs.html
