看到一個(gè)評(píng)論，里面提到了list.sort()和list.strem().sorted()排序的差異。

說(shuō)到list.sort()排序比stream().sorted()排序性能更好。

但沒(méi)說(shuō)到為什么。

有朋友也提到了這一點(diǎn)。

本文重新開(kāi)始，先問(wèn)是不是，再問(wèn)為什么。

真的更好嗎？

先簡(jiǎn)單寫(xiě)個(gè) demo。

ListuserList=newArrayList<>();
Randomrand=newRandom();
for(inti=0;iuserList2=newArrayList<>();
userList2.addAll(userList);

LongstartTime1=System.currentTimeMillis();
userList2.stream().sorted(Comparator.comparing(Integer::intValue)).collect(Collectors.toList());
System.out.println("stream.sort耗時(shí)："+(System.currentTimeMillis()-startTime1)+"ms");

LongstartTime=System.currentTimeMillis();
userList.sort(Comparator.comparing(Integer::intValue));
System.out.println("List.sort()耗時(shí)："+(System.currentTimeMillis()-startTime)+"ms");

輸出

stream.sort耗時(shí)：62ms
List.sort()耗時(shí)：7ms

由此可見(jiàn) list 原生排序性能更好。

能證明嗎？

不一定吧。

再把 demo 變換一下，先輸出stream.sort。

ListuserList=newArrayList<>();
Randomrand=newRandom();
for(inti=0;iuserList2=newArrayList<>();
userList2.addAll(userList);

LongstartTime=System.currentTimeMillis();
userList.sort(Comparator.comparing(Integer::intValue));
System.out.println("List.sort()耗時(shí)："+(System.currentTimeMillis()-startTime)+"ms");

LongstartTime1=System.currentTimeMillis();
userList2.stream().sorted(Comparator.comparing(Integer::intValue)).collect(Collectors.toList());
System.out.println("stream.sort耗時(shí)："+(System.currentTimeMillis()-startTime1)+"ms");

此時(shí)輸出變成了。

List.sort()耗時(shí)：68ms
stream.sort耗時(shí)：13ms

這能證明上面的結(jié)論錯(cuò)誤了嗎？

都不能。

兩種方式都不能證明到底誰(shuí)更快。

使用這種方式在很多場(chǎng)景下是不夠的，某些場(chǎng)景下，JVM 會(huì)對(duì)代碼進(jìn)行 JIT 編譯和內(nèi)聯(lián)優(yōu)化。

LongstartTime=System.currentTimeMillis();
...
System.currentTimeMillis()-startTime

此時(shí)，代碼優(yōu)化前后執(zhí)行的結(jié)果就會(huì)非常大。

基準(zhǔn)測(cè)試是指通過(guò)設(shè)計(jì)科學(xué)的測(cè)試方法、測(cè)試工具和測(cè)試系統(tǒng)，實(shí)現(xiàn)對(duì)一類測(cè)試對(duì)象的某項(xiàng)性能指標(biāo)進(jìn)行定量的和可對(duì)比的測(cè)試。

基準(zhǔn)測(cè)試使得被測(cè)試代碼獲得足夠預(yù)熱，讓被測(cè)試代碼得到充分的 JIT 編譯和優(yōu)化。

下面是通過(guò) JMH 做一下基準(zhǔn)測(cè)試，分別測(cè)試集合大小在 100，10000，100000 時(shí)兩種排序方式的性能差異。

importorg.openjdk.jmh.annotations.*;
importorg.openjdk.jmh.infra.Blackhole;
importorg.openjdk.jmh.results.format.ResultFormatType;
importorg.openjdk.jmh.runner.Runner;
importorg.openjdk.jmh.runner.RunnerException;
importorg.openjdk.jmh.runner.options.Options;
importorg.openjdk.jmh.runner.options.OptionsBuilder;

importjava.util.*;
importjava.util.concurrent.ThreadLocalRandom;
importjava.util.concurrent.TimeUnit;
importjava.util.stream.Collectors;

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Warmup(iterations=2,time=1)
@Measurement(iterations=5,time=5)
@Fork(1)
@State(Scope.Thread)
publicclassSortBenchmark{
@Param(value={"100","10000","100000"})
privateintoperationSize;
privatestaticListarrayList;
publicstaticvoidmain(String[]args)throwsRunnerException{
//啟動(dòng)基準(zhǔn)測(cè)試
Optionsopt=newOptionsBuilder()
.include(SortBenchmark.class.getSimpleName())
.result("SortBenchmark.json")
.mode(Mode.All)
.resultFormat(ResultFormatType.JSON)
.build();
newRunner(opt).run();
}
@Setup
publicvoidinit(){
arrayList=newArrayList<>();
Randomrandom=newRandom();
for(inti=0;ie));
blackhole.consume(arrayList);
}
@Benchmark
publicvoidstreamSorted(Blackholeblackhole){
arrayList=arrayList.stream().sorted(Comparator.comparing(e->e)).collect(Collectors.toList());
blackhole.consume(arrayList);
}
}

性能測(cè)試結(jié)果：

可以看到，list.sort()效率確實(shí)比stream().sorted()要好。

為什么更好？

流本身的損耗

java 的 stream 讓我們可以在應(yīng)用層就可以高效地實(shí)現(xiàn)類似數(shù)據(jù)庫(kù) SQL 的聚合操作了，它可以讓代碼更加簡(jiǎn)潔優(yōu)雅。

但是，假設(shè)我們要對(duì)一個(gè) list 排序，得先把 list 轉(zhuǎn)成 stream 流，排序完成后需要將數(shù)據(jù)收集起來(lái)重新形成 list，這部份額外的開(kāi)銷有多大呢？

我們可以通過(guò)以下代碼來(lái)進(jìn)行基準(zhǔn)測(cè)試。

importorg.openjdk.jmh.annotations.*;
importorg.openjdk.jmh.infra.Blackhole;
importorg.openjdk.jmh.results.format.ResultFormatType;
importorg.openjdk.jmh.runner.Runner;
importorg.openjdk.jmh.runner.RunnerException;
importorg.openjdk.jmh.runner.options.Options;
importorg.openjdk.jmh.runner.options.OptionsBuilder;

importjava.util.ArrayList;
importjava.util.Comparator;
importjava.util.List;
importjava.util.Random;
importjava.util.concurrent.TimeUnit;
importjava.util.stream.Collectors;

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Warmup(iterations=2,time=1)
@Measurement(iterations=5,time=5)
@Fork(1)
@State(Scope.Thread)
publicclassSortBenchmark3{
@Param(value={"100","10000"})
privateintoperationSize;//操作次數(shù)
privatestaticListarrayList;
publicstaticvoidmain(String[]args)throwsRunnerException{
//啟動(dòng)基準(zhǔn)測(cè)試
Optionsopt=newOptionsBuilder()
.include(SortBenchmark3.class.getSimpleName())//要導(dǎo)入的測(cè)試類
.result("SortBenchmark3.json")
.mode(Mode.All)
.resultFormat(ResultFormatType.JSON)
.build();
newRunner(opt).run();//執(zhí)行測(cè)試
}

@Setup
publicvoidinit(){
//啟動(dòng)執(zhí)行事件
arrayList=newArrayList<>();
Randomrandom=newRandom();
for(inti=0;i

	

	方法 stream 測(cè)試將一個(gè)集合轉(zhuǎn)為流再收集回來(lái)的耗時(shí)。

	方法 sort 測(cè)試將一個(gè)集合轉(zhuǎn)為流再排序再收集回來(lái)的全過(guò)程耗時(shí)。

	測(cè)試結(jié)果如下：

	

	可以發(fā)現(xiàn)，集合轉(zhuǎn)為流再收集回來(lái)的過(guò)程，肯定會(huì)耗時(shí)，但是它占全過(guò)程的比率并不算高。

	因此，這部只能說(shuō)是小部份的原因。

	排序過(guò)程

	我們可以通過(guò)以下源碼很直觀的看到。

	

	1 begin方法初始化一個(gè)數(shù)組。

	2 accept 接收上游數(shù)據(jù)。

	3 end 方法開(kāi)始進(jìn)行排序。

	這里第 3 步直接調(diào)用了原生的排序方法，完成排序后，第 4 步，遍歷向下游發(fā)送數(shù)據(jù)。

	所以通過(guò)源碼，我們也能很明顯地看到，stream()排序所需時(shí)間肯定是 > 原生排序時(shí)間。

	只不過(guò)，這里要量化地搞明白，到底多出了多少，這里得去編譯 jdk 源碼，在第 3 步前后將時(shí)間打印出來(lái)。

	這一步我就不做了。

	感興趣的朋友可以去測(cè)一下。

	不過(guò)我覺(jué)得這兩點(diǎn)也能很好地回答，為什么list.sort()比Stream().sorted()更快。

	補(bǔ)充說(shuō)明：

	本文說(shuō)的 stream() 流指的是串行流，而不是并行流。

	絕大多數(shù)場(chǎng)景下，幾百幾千幾萬(wàn)的數(shù)據(jù)，開(kāi)心就好，怎么方便怎么用，沒(méi)有必要去計(jì)較這點(diǎn)性能差異。

	




	審核編輯：劉清