一、JVM內存調優
調優的目的是減少GC頻率和Full GC的次數
1. 什么是Full GC
對年輕代、老年代和永久代進行回收。Full GC的整個過程都會暫停用戶線程。
Young GC(Minor GC)：回收年輕代、Old GC(Major GC)：回收老年代
2. 產生Full GC的原因
1. 老年代空間不足
2. 永久代空間不足
3. 手動調用System.gc()
二、JVM性能調優方法和步驟
1. 監控GC的狀態
使用JVM工具，查看當前日志，分析JVM參數設置是否合理，根據堆內存快照和gc日志，觀察各分代空間大小和GC時間變化。系統崩潰前的現象：
(1)每次回收的時間越來越長
(2)Full GC的次數越來越多
(3)即便觸發Full GC，回收的效果仍然不明顯，老年代越來越大。
2. 生成堆dump文件
通過JMX的MBean生成當前的Heap信息，大小為整個堆大小的hprof文件，或者使用jmap命令生成dump文件。
3. 分析dump文件
使用Visual VM、IBM HeapAnalyzer、JDK自帶的Hprof工具、Mat
4. 分析結果，判斷是否需要優化
如果GC時間短、不頻繁則不需要優化
如果滿足以下指標，一般不需要進行GC：
(1)年輕代GC時間不到50ms
(2)年輕代GC不頻繁，約10秒一次
(3)Full GC時間不到1秒
(4)Full GC執行頻率不頻繁，不低於10分鍾一次
5. 調整GC類型和內存分配
關於堆內存大小設置，需要合適的配置，因為Java進程占用的內存是有限的，堆越大，方法區、棧等占用的內存就越小。堆大小影響的是創建對象的數量和回收耗時，棧大小影響的是創建線程的數量。對於高並發項目，應該適量降低堆大小設置。
6. 不斷的分析和調整
在調整過程中，使用測試機測試，最后才應用到所有服務器。
CMS的調優路線
(圖片引用：https://zhuanlan.zhihu.com/p/58897189)
1. promotion failed
產生原因：老年代空間分配擔保失敗
解決辦法：如果是因為內存碎片產生的擔保失敗，可以通過配置項，在若干次Full GC后進行內存整理。也可以降低新生代的大小，讓老年代更有可能容納新生代。
2.concurrent mode failure
產生原因：由promotion failed觸發、CMS並發清除階段產生的浮動垃圾，老年代放不下
解決辦法：如果是浮動垃圾，可以調低GC的閾值，JDK5默認老年代使用68%的情況下觸發垃圾回收。或者增大老年代/整個堆的大小
3. -XX:+CMSClassUnloadingEnabled
CMS收集器默認不會對永久代進行垃圾回收，除非添加該設置
4. -XX:+ParallelRefProcEnabled
開啟並行引用處理
文字版：
1. 手動調用System.gc導致的Full GC：關閉顯式調用
2. 方法區產生的Full GC：增大方法區內存
3. 出現fail關鍵字
3.1 Promotion Failed
3.2 Concurrent Mode Failed
4. 檢查初始標記和重新標記階段Stop the world時間是否太長
4.1 Ref Proc（處理各種引用）耗時太長：開啟並發
4.2 ClassUnloading耗時太長：擴大永久代空間，並關閉永久代回收
4.3 堆太大：減少大小
5. Minor GC暫停時間太長：縮小年輕代，縮小整個堆
6. Minor GC頻率太高：增大年輕代，增大整個堆
7. 老年代線性增長，可能出現內存泄漏
7.1 有長生命周期的集合類：集合中元素是否持續增長
7.2 有池化對象：池中對象是否持續增長
7.3 有緩存對象：緩存中對象是否持續增長
7.4 使用jmap -histo <pid> 或其他工具觀察對象的創建過程找到可疑對象
三、JVM調優參數參考
1. 堆大小設置
一般將-Xms和-Xmx設定成相同的值，防止內存調整耗費時間
2. 年輕代和老年代
通過NewRadio設置比例。
年輕代大，則Minor GC周期延長，回收時間增加。相應的老年代縮小，Full GC次數頻繁
年輕代小，則Minor GC周期縮短，回收時間減少。相應的老年代增加，Full GC次數減少
如果應用有大量臨時對象，增大年輕代大小，防止老年代頻繁GC。如果應用有很多持久對象，增大老年代大小。
3. 線程堆棧設置
JVM默認為每個線程分配1M的堆棧空間，可適當縮減，以增加並發線程數
參考：
調優策略：https://zhuanlan.zhihu.com/p/58897189
CMS之promotion failed&concurrent mode failure：https://www.jianshu.com/p/ca1b0d4107c5
JVM參數優化：https://blog.csdn.net/liuxinghao/article/details/73963399