1. Stream

1.1. 允許你聲明性地將順序流轉變成並行流

1.2. 能對這些集合執行操作流水線，可以充分利用電腦的多個核

2. 並行流

2.1. 把內容拆分成多個數據塊，用不同線程分別處理每個數據塊的流

2.2. 自動地把工作負荷分配到多核處理器的所有核

2.3. 內部迭代讓你可以並行處理一個流，而無須在代碼中顯式使用和協調不同的線程

2.4. 對順序流調用parallel方法，你可以將流轉換成並行流

2.5. 並行流調用sequential方法就可以把它變成順序流

2.6. 最後一次parallel或sequential調用會影響整個流水線

2.7. 內部使用了預設的ForkJoinPool

2.7.1. 預設的線程數量就是你的處理器數量

2.7.2. Runtime.getRuntime().availableProcessors()得到

2.7.3. java.util.concurrent.ForkJoinPool.common.parallelism來修改線程池大小

3. Java微基準套件

3.1. Java microbenchmark harness, JMH

3.2. 一個以聲明方式幫助大家創建簡單、可靠微基準測試的工具集

3.3. 支持Java

3.4. 支持可以運行在Java虛擬機（Java virtual machine, JVM）上的其他語言

3.5. 選擇適當的數據結構往往比並行化演算法更重要

3.5.1. LongStream.rangeClosed

3.6. 並行軟體的行為和性能有時是違反直覺的，因此一定要測量，確保你並沒有把程式拖得更慢

4. 並行化的代價

4.1. 並行化過程本身需要對流做遞歸劃分

4.2. 把每個子流的歸約操作分配到不同的線程

4.3. 然後把這些操作的結果合併成一個值

4.4. 多個核之間移動數據的代價也可能比你想的要大

4.4.1. 保證在核中並行執行工作的時間比在核之間傳輸數據的時間長

4.5. 很多情況下不可能或不方便並行化

4.5.1. 如果結果錯了，算得快就毫無意義了

5. 高效使用並行流

5.1. 適用於要處理的元素數量龐大，或處理單個元素特別耗時的時候

5.2. 並行流並不總是比順序流快

5.2.1. 用適當的基準來檢查其性能

5.3. 自動裝箱和拆箱操作會大大降低性能

5.4. 有些操作本身在並行流上的性能就比順序流差

5.4.1. limit和findFirst等依賴於元素順序的操作

5.4.2. findAny會比findFirst性能好，因為它不一定要按順序來執行

5.5. 調用unordered方法來把有序流變成無序流

5.5.1. 對無序並行流調用limit可能會比單個有序流（比如數據源是一個List）更高效

5.6. 流的操作流水線的總計算成本

5.6.1. 設N是要處理的元素的總數，Q是一個元素通過流水線的大致處理成本，則N*Q就是這個對成本的一個粗略的定性估計

5.6.2. Q值較高就意味著使用並行流時性能好的可能性比較大

5.7. 對於較小的數據量，選擇並行流幾乎從來都不是一個好的決定

5.8. 流背後的數據結構是否易於分解

5.8.1. ArrayList的拆分效率比LinkedList高得多

5.9. 終端操作中合併步驟的代價是大是小

6. 分支/合併框架

6.1. 分治演算法的並行版本

6.2. 以遞歸方式將可以並行的任務拆分成更小的任務，然後將每個子任務的結果合併起來生成整體結果

6.3. ExecutorService介面的一個實現，它把子任務分配給線程池（稱為ForkJoinPool）中的工作線程

6.4. 對一個任務調用join方法會阻塞調用方，直到該任務做出結果

6.5. 不應該在RecursiveTask內部使用ForkJoinPool的invoke方法

6.6. 應該始終直接調用compute或fork方法，只有順序代碼才應該用invoke來啟動並行計算

6.7. 對子任務調用fork方法可以把它排進ForkJoinPool

6.8. 工作竊取

6.8.1. 隨機選了一個別的線程，從隊列的尾巴上“偷走”一個任務

7. Spliterator

7.1. 一種自動機制來為你拆分流

7.2. 代表“可分迭代器”（splitable iterator）

7.3. 用於遍曆數據源中的元素，但它是為了並行執行而設計的

7.4. 特性是通過characteristics方法聲明的

7.5. Java沒有元組（tuple，用來表示由異類元素組成的有序列表的結構，不需要包裝對象），所以你必須創建一個新類來把狀態封裝起來