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的堆是一個好的開始