1. 異常

1.1. 代碼應該僅在發生意料之外的事情時拋出異常

1.1.1. 防禦性編程性能好

1.2. 異常的處理成本未必很高

1.2.1. 應該只在適當的時候使用

1.2.2. 棧越深，處理異常的成本就越高

1.3. 對於頻繁創建的系統異常，JVM會優化獲取棧軌跡的性能開銷

1.4. 在異常中禁用棧軌跡有時可以提高性能，但會丟失一些關鍵信息

2. 日誌

2.1. 一直開啟GC日誌

2.2. 基本原則

2.2.1. 在日誌的數據和日誌的級別之間找到平衡

2.2.2. 使用細粒度的日誌記錄器

2.2.2.1. 開啟過多的日誌通常會改變生產環境，使原來的問題無法顯現

2.2.3. 即使沒有開啟日誌，也很容易在無意間寫出具有副作用的日誌代碼

2.3. 應該包含大量日誌以幫助用戶找出問題所在，但日誌預設應該是關閉的

2.3.1. 如果日誌記錄器的參數需要調用方法或者分配對象，那麼不要忘記在調用記錄器之前檢驗日誌級別

3. Java集合API

3.1. 根據演算法選擇集合類是至關重要的

3.2. LinkedList不適合搜索

3.3. HashMap用於訪問一段隨機的數據

3.4. TreeMap用於數據需要保持有序

3.5. HashMap是根據鍵值查找條目的最快方法

3.6. ArrayList用於數據通過索引訪問

3.6.1. 不適用將數據插入到數組中

3.7. 集合的大小會對性能產生很大的影響

3.7.1. 太大，會拖慢垃圾回收器的速度

3.7.2. 太小，會需要大量的複製操作和大小調整操作

3.8. 使用同步集合，降低由此帶來的性能影響

3.8.1. 是否值得花費時間和精力為了線程安全而面向未來編程

4. Lambda和匿名類

4.1. Lambda並不是通過匿名類實現的

4.2. Lambda的代碼會創建一個靜態方法

4.2.1. 該方法通過一個特殊的幫助類來調用

4.3. 匿名類是真正的Java類

4.3.1. 它有單獨的類文件，並會通過類載入器載入

4.3.2. 啟動有很多匿名類（相對於有很多Lambda）的應用程式，可能會出現更大的差異

4.4. 性能幾乎沒有區別

4.4.1. 在類載入很重要的環境中，Lambda會稍快一些

5. 流和過濾器

5.1. 流最重要的性能優勢

5.1.1. 它們被實現為延遲處理的數據結構

5.1.2. 延遲處理的過濾器實現可以在完成需要做的事情後結束處理，這樣處理的數據更少

5.2. 過濾器比迭代器快得多的原因

5.2.1. 它們可以進行演算法上的優化

5.3. 即使處理整個數據集，單個過濾器的性能也會略優於迭代器

5.4. 多個過濾器是有開銷的，要確保編寫性能良好的過濾器

6. 對象序列化

6.1. 一種將對象的二進位狀態寫出來，以便之後重新創建的方法

6.2. 數據的序列化可能是很大的性能瓶頸

6.3. 降低對象序列化成本的方法是序列化更少的數據

6.3.1. 將欄位標記為transient來做到，標記後它們預設不會被序列化

6.3.2. 可以讓序列化更快，並減少需要傳輸的數據量

6.4. 優化序列化往往就是對對象引用進行特殊處理

6.4.1. 做得正確，序列化代碼的性能會大幅提高

6.4.2. 做得不正確，就會引入不易察覺的bug

6.4.3. 避免寫出重覆的對象引用

6.5. 壓縮序列化數據，傳輸速度會更快

6.5.1. 壓縮序列化數據然後延遲解壓會非常有用，特別是當目標是節省CPU記憶體而不是節省CPU時間的時候

6.5.2. 在快速的網路上，壓縮數據的時間很容易比傳輸更少的數據所節省的時間長，在較慢的網路上，情況可能正好相反

6.6. 實現Externalizable介面

6.6.1. 當writeObject()方法調用defaultWriteObject()方法時

6.6.1.1. Serializable介面會寫出非瞬時欄位

6.6.1.2. Externalizable介面不會寫出非瞬時欄位

6.6.2. Externalizable類必須明確地寫出它要傳輸的所有欄位

6.6.2.1. 不管這些欄位是不是瞬時的

6.7. 即使一個對象的所有欄位都是瞬時的，最好還是實現Serializable介面並調用defaultWriteObject()方法

6.7.1. 會讓代碼更容易維護

6.8. 通過writeObject()方法和readObject()方法進行的其他優化可以大幅加快序列化的速度