資訊專欄INFORMATION COLUMN
摘要：而一個(gè)編譯器本身是有一個(gè)上限的，雖然大部分情況下是用不滿的。我們將此稱作友好或者不友好的分割。同時(shí)，也不要無(wú)緣無(wú)故就覺得人家損害了你應(yīng)用的性能，那是你自己用得不好。
Java 8提供的流的基于Lambda表達(dá)式的函數(shù)式的操作寫法讓人感覺很爽，筆者也一直用的很開心，直到看到了Java8 Lambda表達(dá)式和流操作如何讓你的代碼變慢5倍，筆者當(dāng)時(shí)是震驚的，我讀書少，你不要騙我。瞬間我似乎為我的Server Application速度慢找到了一個(gè)很好地鍋，不過(guò)這個(gè)跟書上講的不一樣啊。于是筆者追本溯源，最后找到了始作俑者自己的分析：原文
不久之前我在社區(qū)內(nèi)發(fā)表了這篇文章： I mused about the performance of Java 8 streams ，上面的測(cè)試結(jié)果貌似很有道理。其中一個(gè)測(cè)試是將傳統(tǒng)的for-循環(huán)與Stream進(jìn)行了比較。很多人表示了震驚、不相信等等很多很多的情緒，甚至有人直接說(shuō)Stream是個(gè)什么鬼，哪涼快哪呆著去。這是沒有道理的，畢竟不能通過(guò)一個(gè)簡(jiǎn)單地只是一個(gè)環(huán)境下的測(cè)試就否定這些。
在之前的測(cè)評(píng)中，在500,000個(gè)隨機(jī)的整形數(shù)的數(shù)組的遍歷中，我們得出的結(jié)論是for-循環(huán)的速度會(huì)比Stream的速度快上15倍。其中for-循環(huán)的數(shù)組如下所示：
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];
同樣的，我們建立了一個(gè)原始類型的IntStream：
int m = Arrays.stream(ints)
.reduce(Integer.MIN_VALUE, Math::max);
在我們這個(gè)過(guò)時(shí)的設(shè)備上（雙核）跑出來(lái)的結(jié)果是：
int-array, for-loop : 0.36 ms int-array, seq. stream: 5.35 ms
for循環(huán)的方式明顯的比Stream流要快很多很多，然后我們選擇了另一臺(tái)4核的設(shè)備，發(fā)現(xiàn)這個(gè)比例因子變成了4.2(原來(lái)是15)。這個(gè)結(jié)果的詳細(xì)信息可以看Nicolai Parlog’s blog 這個(gè)文章：
正如我們所料，不同的環(huán)境可能會(huì)引發(fā)不同的結(jié)果。不過(guò)我們?cè)u(píng)測(cè)的核心：for-循環(huán)速度奏是比Stream快，在不同的平臺(tái)上是一致的。
接下來(lái)，我們不再測(cè)試原始類型，改用了ArrayList
ArrayList, for-loop : 6.55 ms ArrayList, seq. stream: 8.33 ms
是的，for-循環(huán)的速度確實(shí)還是會(huì)快一點(diǎn)，但是很明顯這種差距縮小了。這個(gè)結(jié)果并不令人驚訝，實(shí)際上整個(gè)測(cè)試的性能主要取決于內(nèi)存訪問(wèn)與遍歷這兩大塊。其中內(nèi)存訪問(wèn)這個(gè)還受限制于硬件本身，所以不同的平臺(tái)上會(huì)有不同的結(jié)果。實(shí)際上在我們的測(cè)試中出現(xiàn)這樣的結(jié)果并不會(huì)令人驚訝，畢竟我們特意選擇了一個(gè)比較極端的情況，代表了范圍內(nèi)的某個(gè)極端，可以解釋如下：
我們將for-loops與Streams進(jìn)行了比較。循環(huán)本身是JIT友好的。編譯器本身有了40年以上的經(jīng)驗(yàn)，然后我們選擇了循環(huán)這個(gè)JIT編譯器重點(diǎn)優(yōu)化的部分。這是所謂的某個(gè)極端：一個(gè)JIT友好的，高度優(yōu)化的訪問(wèn)序列元素的方法。而如果是使用流的話也就意味著會(huì)在主框架內(nèi)進(jìn)行調(diào)用，不可避免地增加內(nèi)存調(diào)用。而一個(gè)JIT編譯器本身是有一個(gè)上限的，雖然大部分情況下是用不滿的。因此，我們將這種情況分為JIT友好與不友好，而for-循環(huán)本身是處于JIT友好的這一邊，因此它自然能夠贏得這個(gè)測(cè)試，并沒有神馬奇怪。
我們將原始類型的序列與引用類型的序列進(jìn)行了比較。這兩種情況可以用緩存友好/不友好來(lái)區(qū)分。一個(gè)原始類型int的序列是非常緩存友好的，特別是當(dāng)未來(lái)Java引入不可變序列的時(shí)候。而一個(gè)引用類型的序列，即使用了基于數(shù)組的，就像ArrayList的這樣的存儲(chǔ)，也是只有很小的概率進(jìn)行很好地緩存。每次獨(dú)立地對(duì)于序列成員的訪問(wèn)需要獲取指針指向的地址然后獲取其內(nèi)容，也就意味著緩存的失效。很明顯地，一個(gè)使用了int[]的for-循環(huán)肯定處在緩存友好這一邊，自然與序列引用的Stream相比性能上要好上很多。
我們將元素輕量級(jí)使用與CPU密集型使用相比。更重要的是，我們將這種兩個(gè)兩個(gè)的比較尋找最大值的計(jì)算與Taylor相似度下尋找正弦值的計(jì)算進(jìn)行了比較。在下面一個(gè)實(shí)驗(yàn)中，我們會(huì)以相對(duì)而言復(fù)雜一點(diǎn)的CPU密集型的運(yùn)算為例，可能獲取到這個(gè)值需要一分鐘的時(shí)間。我們將此稱作CPU友好或者CPU不友好的分割。一般來(lái)說(shuō)，對(duì)于序列中的元素進(jìn)行重量級(jí)的CPU密集型的運(yùn)算的時(shí)候，也就是所謂的CPU不友好運(yùn)算時(shí)，評(píng)測(cè)結(jié)果往往由CPU的運(yùn)算速度決定，而對(duì)于上面講的緩存缺失以及JIT循環(huán)的優(yōu)化就變得不那么重要了。
講了這么多，我們已經(jīng)可以發(fā)現(xiàn)上面評(píng)測(cè)中對(duì)于int[]類型的數(shù)組中尋找最大值的這件事是受到JIT友好以及緩存友好這兩個(gè)因素決定的。這種情況下，當(dāng)然for-循環(huán)會(huì)占了很大優(yōu)勢(shì)，如果沒做到這樣才會(huì)讓人驚訝呢。那么如果我們對(duì)于上文中所講的CPU密集型的情況，這也是一種極端情況，進(jìn)行評(píng)測(cè)，其中for-循環(huán)式這樣的：
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));
最后的結(jié)果是：
for``-loop?? : ``11.82` `ms seq. stream: ``12.15` `ms
這個(gè)評(píng)測(cè)依舊是在上文說(shuō)到的那個(gè)老舊的機(jī)器上進(jìn)行的。確實(shí)for-循環(huán)的效率是比Stream要快的，不過(guò)可以看得出來(lái)這種差距不再明顯了。換種說(shuō)法，這種差距在統(tǒng)計(jì)評(píng)測(cè)的角度來(lái)看還是很重要的，不過(guò)在實(shí)際的應(yīng)用過(guò)程中已經(jīng)無(wú)足輕重了。到這里我們證明了與上次評(píng)測(cè)相悖的一個(gè)觀點(diǎn)：其實(shí)Stream與for-循環(huán)之間的性能并木有很大的差異。
最后來(lái)總結(jié)一波，在有些情況下，Stream的效率確實(shí)會(huì)比for-循環(huán)要慢上很多倍，然后在其他大部分情況下是沒有蝦米差異的。你可以覺得Stream很酷然后就去使用它，或者為了優(yōu)化你的應(yīng)用的性能而依舊選擇舊的語(yǔ)法。同時(shí)，也不要無(wú)緣無(wú)故就覺得人家Stream損害了你應(yīng)用的性能，那是你自己用得不好。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/65311.html
摘要：內(nèi)部迭代與使用迭代器顯式迭代的集合不同，流的迭代操作是在背后進(jìn)行的。流只能遍歷一次請(qǐng)注意，和迭代器類似，流只能遍歷一次。 流（Stream） 流是什么 流是Java API的新成員，它允許你以聲明性方式處理數(shù)據(jù)集合（通過(guò)查詢語(yǔ)句來(lái)表達(dá)，而不是臨時(shí)編寫一個(gè)實(shí)現(xiàn)）。就現(xiàn)在來(lái)說(shuō)，你可以把它們看成遍歷數(shù)據(jù)集的高級(jí)迭代器。此外，流還可以透明地并行處理，你無(wú)需寫任何多線程代碼了！我會(huì)在后面的筆記中...
摘要：編程語(yǔ)言將函數(shù)作為一等公民，函數(shù)可以被作為參數(shù)或者返回值傳遞，因?yàn)樗灰暈閷?duì)象。是表示已注釋接口是函數(shù)接口的注釋。如果一個(gè)函數(shù)有一個(gè)或多個(gè)參數(shù)并且有返回值呢為了解決這個(gè)問(wèn)題，提供了一系列通用函數(shù)接口，在包里。 【編者按】雖然 Java 深得大量開發(fā)者喜愛，但是對(duì)比其他現(xiàn)代編程語(yǔ)言，其語(yǔ)法確實(shí)略顯冗長(zhǎng)。但是通過(guò) Java8，直接利用 lambda 表達(dá)式就能編寫出既可讀又簡(jiǎn)潔的代碼。作者...
摘要：月底了，又到了我們總結(jié)這一個(gè)月技術(shù)干貨的時(shí)候了，又到了我們給粉絲免費(fèi)送書的日子了。 月底了，又到了我們總結(jié)這一個(gè)月 Java 技術(shù)干貨的時(shí)候了，又到了我們給粉絲免費(fèi)送書的日子了。 7 月份干貨總結(jié) Oracle 發(fā)布了一個(gè)全棧虛擬機(jī) GraalVM 一文帶你深入拆解 Java 虛擬機(jī) 圖文帶你了解 8 大排序算法 Spring Boot 2.x 新特性總結(jié)及遷移指南 Spring B...
摘要：實(shí)戰(zhàn)讀書筆記第一章從方法傳遞到接著上次的，繼續(xù)來(lái)了解一下，如果繼續(xù)簡(jiǎn)化代碼。去掉并且生成的數(shù)字是萬(wàn)，所消耗的時(shí)間循序流并行流至于為什么有時(shí)候并行流效率比循序流還低，這個(gè)以后的文章會(huì)解釋。 《Java8實(shí)戰(zhàn)》-讀書筆記第一章（02） 從方法傳遞到Lambda 接著上次的Predicate，繼續(xù)來(lái)了解一下，如果繼續(xù)簡(jiǎn)化代碼。 把方法作為值來(lái)傳遞雖然很有用，但是要是有很多類似與isHeavy...
摘要：可以使用方法替換常規(guī)循環(huán)以上代碼的產(chǎn)出所有這些原始流都像常規(guī)對(duì)象流一樣工作，但有以下不同之處原始流使用專門的表達(dá)式，例如代替或代替。原始流支持額外的終端聚合操作，以上代碼的產(chǎn)出有時(shí)將常規(guī)對(duì)象流轉(zhuǎn)換為基本流是有用的，反之亦然。 本文提供了有關(guān)Java 8 Stream的深入概述。當(dāng)我第一次讀到的Stream API，我感到很困惑，因?yàn)樗犉饋?lái)類似Java I/O的InputStream，...
閱讀 1720·2021-09-22 10:02
閱讀 1942·2021-09-02 15:40
閱讀 2845·2019-08-30 15:55
閱讀 2255·2019-08-30 15:44
閱讀 3602·2019-08-30 13:18
閱讀 3232·2019-08-30 11:00
閱讀 1956·2019-08-29 16:57
閱讀 571·2019-08-29 16:41
