我們來通過兩個任務來進行測試，一個是cpu密集型的，一個是io密集型的，同樣的功能，分别在4種場景下進行測試。不同實作中線程的數量也是一個非常重要的因素，是以這個也是我們測試的目标之一。測試機器共有8個核，是以我們分别使用4，8，16，32個線程來進行測試。對每個任務而言，我們還會測試下單線程的版本，不過這個在圖中并沒有标出來，因為它的時間要長得多。如果想了解這些測試用例是如何運作的，你可以看一下最後的基礎庫一節。我們開始吧。
在本次測試中我們生成了一個超大的文本檔案，并通過相同的方法來建立索引。我們來看下結果如何：
單線程執行時間：176，267毫秒，大約3分鐘。 注意，上圖是從20000毫秒開始的。
從圖中第一個容易注意到的就是柱狀圖的形狀——光從這4個資料就能大概了解到各個實作的表現是怎樣的了。8個線程到16個線程這裡有所傾斜，這是因為某些線程阻塞在了檔案io這裡，是以增加線程能更好地使用cpu資源。而當加到32個線程時，由于增加了額外的開銷，性能又開始會變差。
并行流所提供的可不止是文法糖（這裡指的并不是lambda表達式）,而且它的性能也比fork/join架構以及executorservice要更好。索引完6gb大小的檔案隻需要24.33秒。請相信java，它的性能也能做到很好。
并行流為什麼會影響性能，這裡也給你上了一課。這在本來就運作着多線程應用的機器上是有可能的。由于可用的線程本身就很少了，直接使用fork/join架構要比使用并行流更好一些——兩者的結果相差5秒，大約是18%的性能損耗。
測試中使用預設線程池大小（預設值是機器的cpu核數，在這裡是8）的并行流，跟使用16個線程相比要慢上2秒。也就是說使用預設的池大小則要慢了7%。這是由于阻塞的io線程導緻的。由于有很多線程處于等待狀态，是以引入更多的線程能夠更好地利用cpu資源，當其它線程在等待排程時不至于讓它們閑着。
如果改變并行流的預設的fork/join池的大小？你可以通過一個jvm參數來修改公用的fork/join線程池的大小：
（預設情況下，所有的fork/join任務都會共用同一個線程池，線程的數量等于cpu的核數。好處就是當線程空閑下來時可以收來處理其它任務。）
并發能夠提升7.25倍的性能，考慮到機器是8核的，也就是說接近是8倍的提升！還差的那點應該是消耗線上程的開銷上了。不僅如此，即便是測試中表現最差的并行版本，也就是4個線程的并行流實作（30.23秒），也比單線程的版本（176.27秒）要快5.8倍。
下面是測試的結果：
單線程執行時間：118，127毫秒，大約2分鐘 注意，上圖是從20000毫秒開始的
和io測試中不同，這裡并沒有io調用，是以8個線程和16個線程的差别并不大，fork/join的版本例外。由于它的反常表現，我們還多運作了好幾組測試以確定得到的結果是正确的，但事實表明，結果仍是一樣。希望你能在下方的評論一欄說一下你對這個的看法。
我們看到，不同的實作版本最快的結果都是一樣的，大約是28秒左右。不管實作的方法如何，結果都大同小異。但這并不意味着使用哪種方法都一樣。請看下面這點。
這點非常有意思。在本次測試中，我們發現，并行流的16個線程的再次勝出。不止如此，在這次測試中，不管線程數是多少，并行流的表現都是最好的。
除此之外，在運作計算密集型任務時，并行版本的優勢要比帶有io的測試要減少了2倍。由于這是個cpu密集型的測試，這個結果倒也說得過去，不像前面那個測試中那樣，減少cpu的等待io的時間能獲得額外的收益。
我們是在ec2的c3.2xlarge執行個體上運作的本次測試，它有8個vcpu核以及15gb的記憶體。vcpu是因為這裡用到了超線程技術，是以實際上隻有4個實體核，但每個核模拟成了兩個。對作業系統的排程器而言，認為我們一共有8個核。為了盡可能的公平，每個實作都運作了10遍，并選擇了第2次到第9次的平均運作時間。也就是一共運作了260次！處理時長也非常重要。我們所選擇的任務的運作時間都會超過20秒，是以時間差異能很容易看出來，而不太受外部因素的影響。