1. GC觸發條件

1.1. 當新生代滿的時候

1.1.1. Minor GC會被觸發

1.2. 當老年代滿的時候

1.2.1. Full GC會被觸發

1.3. 當堆快要填滿時

1.3.1. 併發GC（如果適用）會被觸發

2. 強制開啟GC

2.1. System.gc()方法

2.1.1. 總是會觸發Full GC（即使JVM運行的是G1GC或者CMS）

2.1.2. 並不會讓應用程式更高效

2.1.2.1. 只是讓GC比其他情況更早開啟，也只是將性能的影響延遲了

2.1.3. 調用這個方法從來都不是好主意

2.2. 例外

2.2.1. 在做性能監控或基準測試時

2.2.1.1. 對於運行少量代碼的小型基準測試，為了加快預熱JVM，在測量期之前強制執行GC有意義

2.2.2. 對堆進行分析時，在堆轉儲之前強制觸發Full GC是個好主意

2.2.3. 遠程方法調用

2.2.3.1. Remote Method Invocation，RMI

2.2.3.2. 作為分散式垃圾回收器的一部分，它每小時調用一次System.gc()方法

2.2.3.3. -Dsun.rmi.dgc.server.gcInterval=N

2.2.3.4. -Dsun.rmi.dgc.client.gcInterval=N

2.2.3.5. N以毫秒為單位

2.2.3.6. 預設值是3 600 000（1小時）

2.3. -XX:+DisableExplicitGC

2.3.1. 阻止強制GC操作

2.3.2. 預設false

3. CPU使用率

3.1. 要確保CPU告警不是由Full GC引起的100%CPU使用率造成的

3.2. 也不是由後臺併發處理線程引起的CPU高峰持續時間更長（但使用率更低）造成的

3.3. Java應用程式來說是很正常的

4. 選擇GC演算法

4.1. 在JDK 8中，要如何選擇則取決於你的應用程式

4.2. 在單CPU的機器上預設使用Serial垃圾回收器

4.2.1. 包括單個CPU的虛擬機和限制只能使用一個CPU的Docker容器

4.3. 當在單CPU機器上運行CPU密集型應用程式時，即使這個CPU是超線程的，使用Serial垃圾回收器也更有意義

4.4. 如果平均響應時間是最重要的目標，Serial垃圾回收器是更好的選擇

4.5. 在批處理任務中，CPU會在很長一段時間內100%忙碌，Serial垃圾回收器有明顯的優勢

4.6. 堆很小（比如100 MB）的應用程式，無論可用的核心數量是多少，使用Serial垃圾回收器可能都會有更好的表現

4.7. 如果一個長期運行的應用程式線程占用了唯一可用的CPU，那麼G1 GC不是一個好的選擇

4.8. 在JDK 11中，G1 GC通常是更好的選擇

4.9. 對於大多數應用程式來說，G1 GC的演算法是更好的選擇

4.10. 如果你想優化第99百分位響應時間，那麼G1 GC更好

4.11. 在同樣的硬體上處理非CPU密集型任務，G1GC是更好的選擇

4.12. 當你選擇G1 GC時，需要有足夠的CPU供後臺線程運行

4.13. 在CPU周期足夠的情況下，即使Serial垃圾回收器是預設的選擇，G1 GC一般也會表現得更好

4.14. 如果伺服器缺少CPU周期，會導致G1 GC和應用程式線程競爭CPU，那麼G1 GC的響應時間會更長

4.15. 如果更看重交互處理和響應時間，那麼Throughput垃圾回收器很難戰勝G1 GC

4.16. 如果優化伺服器之後沒有了Full GC，那麼G1 GC和Throughput垃圾回收器通常會得到相似的結果

4.16.1. Throughput垃圾回收器遇到的Full GC越多，G1 GC的平均響應時間、第90百分位響應時間和第99百分位響應時間就會越短

4.17. 當應用程式的運行時間是關鍵時，如果Throughput垃圾回收器的應用程式線程停頓時間比G1 GC少，那麼它就更有優勢

4.17.1. 沒有（或很少）Full GC。

4.17.2. 老年代常常是滿的，G1 GC後臺線程有更多工作要做

4.17.3. G1 GC線程亟需CPU周期

4.18. 在多CPU機器上運行CPU密集型任務時，Throughput垃圾回收器更有意義

4.19. 即使任務不是CPU密集型的，如果它產生的Full GC相對較少或者老年代一般是滿的，Throughput垃圾回收器也可能是更好的選擇