1. 物件重用

1.1. 原因

1.1.1. 許多物件的初始化成本很高，權衡了增加的GC時間之后，還是重用物件的效率更高

1.2. 只適用于初始化成本很高且數量較少的一組物件

1.2.1. 被重用的物件會在堆中停留很長時間，如果堆中有大量物件，創建新物件的空間就更少了，因此GC操作會更頻繁，

1.3. 方式

1.3.1. 物件池

1.3.1.1. 執行緒池化可以節省創建執行緒的時間

1.3.1.2. 在池中有少量物件并不會對GC效率產生太大影響，但堆中充滿池化物件時會大大減慢GC的速度

1.3.2. 執行緒區域變數

1.3.2.1. 亂數生成器作為執行緒區域變數，可以節省使用亂數種子創建生成器所需的時間

1.4. 特點

1.4.1. 初始化物件需要很長的時間

1.4.2. 共享的物件數量往往很少

1.4.2.1. 它們對GC操作的影響降到了最低，因為它們不足以減慢GC周期

1.5. 應用場景

1.5.1. 執行緒池

1.5.1.1. 執行緒初始化的成本很高

1.5.2. JDBC連接池

1.5.2.1. 資料庫連接初始化的成本很高

1.5.3. 大陣列

1.5.3.1. 每個元素都必須初始化為基于0的默認值（null、0或false，視情況而定）

1.5.4. 原生NIO緩沖區

1.5.4.1. 無論緩沖區有多大，分配一個直接的java.nio.Buffer（呼叫allocateDirect()方法回傳的緩沖區）都是成本很高的操作

1.5.4.2. 最好是創建一個大的緩沖區，然后通過按需切片的方式來管理緩沖區，以便在將來的操作中回傳它們重新使用

1.5.5. 與安全相關的類

1.5.5.1. MessageDigest、Signature以及其他安全演算法的實體

1.5.6. 字串編碼器和解碼器物件

1.5.7. StringBuilder幫助類

1.5.8. 亂數生成器

1.5.8.1. Random類和（特別是）SecureRandom類的實體

1.5.9. 從DNS查詢中獲得的名字

1.5.9.1. 網路查詢的成本很高

1.5.10. ZIP編碼器和解碼器

1.5.10.1. 初始化成本并不是特別高，但是它們的釋放成本很高

1.5.10.2. 依賴物件終結（finalization）來確保它們使用的原生記憶體也被釋放了

2. 物件池

2.1. 大小可能很難設定正確

2.2. 不能直接讓物件退出作用域，程式員必須將物件返還到池中

2.3. 持有大量物件會降低GC的效率（有時會大幅降低）

2.4. 必然需要同步，如果物件被頻繁地洗掉和替換，物件池可能會存在大量競爭

2.5. 普通類的大型物件池帶來的性能問題肯定會比解決的問題還多

2.6. 限流對池性能的影響是有利的，池允許對稀缺資源的訪問進行限流

3. 執行緒區域變數

3.1. 在執行緒內總是可用的，不需要顯式地歸還

3.2. 不能對資源的訪問進行限流

3.2.1. 除非執行緒數量本身可以起到限流的作用

3.3. 不需要同步

3.3.1. 只能在單個執行緒內使用

3.3.2. 使用ThreadLocalRandom類性能會更好

3.4. 如果執行緒和可重用物件之間有一一對應的關系，那么執行緒區域變數更容易使用

4. 不確定參考

4.1. indefinite reference

4.2. 表示任何特殊型別的參考

4.2.1. 軟參考或弱參考

4.2.2. 實際上是一個物件實體

4.3. 更多地用于快取耗時的計算或資料庫查詢的結果，而不是用于重用一個簡單物件

4.4. 對垃圾回收器的影響

4.4.1. 會導致應用程式使用更多的記憶體

4.4.2. 不確定參考被垃圾回收器回收至少需要兩個GC周期，這對垃圾回收器的影響更大

4.4.2.1. 在最壞的情況下，參考佇列不會被立即清理，而是需要經過很多GC周期后才會釋放一切物件

4.5. -XX:+PrintReferenceGC標志

4.5.1. 看到處理參考所花費的時間

4.5.2. 默認為false

4.6. 不確定參考會消耗自身的記憶體，而且會長時間持有其他物件的記憶體，應盡量少用

5. 參考

5.1. reference

5.2. 一個參考（或物件參考）可以是任何型別的參考

5.3. 強參考、弱參考和軟參考等

6. 所引物件

6.1. referent

6.2. 將另一個參考（幾乎總是強參考）嵌入到不確定參考類的實體中，被封裝的這個物件被稱為所引物件

7. 軟參考

7.1. Soft Reference

7.2. 當相關物件在未來有很大概率被重用，而你想讓垃圾回收器回收最近沒有用到的物件時使用

7.2.1. 軟參考可以長期持有物件，它會提供一個簡單的、GC友好的LRU快取

7.3. 本質上是一個大型的、最近最少使用的（LRU）物件池

7.4. 獲得良好性能的關鍵是要確保它被及時清理

7.5. 清理時機

7.5.1. 所引物件必須沒有被其他的強參考所參考

7.5.2. 軟參考是指向所引物件的唯一參考，那么當軟參考最近沒有被訪問時，所引物件就會在下個GC周期被釋放

7.6. -XX:SoftRefLRUPolicyMSPerMB=N標志

7.6.1. 默認值是1000

7.7. 長期運行的應用程式也可以考慮增加SoftRefLRUPolicyMSPerMB的值的條件

7.7.1. 堆中有大量空閑空間可用

7.7.2. 軟參考的訪問頻率不高

7.8. 不要使用過多的軟參考，它們很容易填滿整個堆

7.9. 當物件的數量不太多時，軟參考的效果才會好，否則，還是要考慮使用更傳統的、大小有界的物件池，并且以LRU快取形式實作

8. 弱參考

8.1. weak reference

8.2. 在相關所引物件會被幾個執行緒同時使用時使用

8.3. 當強參考被清理時，弱參考立即被清理

8.4. 垃圾回收器在每個GC周期都會回收只有弱參考的物件

8.5. 集合類常常是記憶體泄漏的源頭

8.5.1. WeakHashMap和WeakIdentityMap

8.5.2. 基于不確定參考的集合可能很有用，但是應該謹慎使用

9. 終結器和最終參考

9.1. 不鼓勵使用終結器，應該使用新的Cleaner類

9.2. Object類的finalize()方法

9.2.1. 糟糕的方法，你應該盡量避免使用

9.2.2. 在JDK 11中被廢棄了

9.3. Cleaner（清理器）物件

9.3.1. 使用新的java.lang.ref.Cleaner類代替finalize()方法會容易很多

9.3.2. 在JDK 11中使用

9.3.3. 執行清理的物件不能包含指向需要被清理的物件的參考

9.3.3.1. 因為lambda太容易參考外部類了，不鼓勵開發人員使用lambda，而是要使用類

9.4. 如果你必須使用終結器，請確保將物件訪問的記憶體保持在最低限度

9.5. 使用另一種型別的不確定參考，而不是隱式地使用Finalizer參考

9.5.1. PhantomReference類（虛參考）

9.5.1.1. JDK 11使用

9.6. 終結器佇列

9.6.1. 當所引物件符合GC條件時，用來處理Finalizer參考的參考佇列

9.6.2. 命令來處理終結器佇列

9.6.2.1. % jcmd process_id GC.run_finalization

9.6.2.2. % jmap -finalizerinfo process_id

10. 普通物件指標

10.1. ordinary object pointer,oop

10.2. -XX:+UseCompressedOops

10.2.1. 對于4 GB到32 GB的堆，應該使用

10.2.2. 只要堆的最大大小小于32GB，標志默認啟用

10.3. 使用了31 GB的堆并啟用了壓縮的oop的程式，通常比使用了33 GB堆的程式快

10.4. 最好使用小于32 GB的堆，或者至少比32 GB大幾個GB的堆

10.5. 一旦更多的記憶體被添加到堆中以彌補未壓縮的參考所使用的空間，GC周期的數量就會減少

10.6. 規劃至少38 GB的堆是一個好的開始

標籤：其他

上一篇：讀Java性能權威指南（第2版）筆記13_堆記憶體下

下一篇：Java動態代理