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垃圾回收器也可能是更好的選擇
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/546617.html
標籤：其他
上一篇：MybatisPlus 快速上手