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()方法進行的其他優化可以大幅加快序列化的速度
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/545200.html
標籤：其他
上一篇：day06-動態SQL陳述句