內存分析：
1、通過 ps -aux(或-elf) | grep java(或shua-xiao)獲取進程PID
2、通過 jmap -histo <pid> 查看堆內存中存活的對象
按照對象所占內存大小排序，顯示了存活對象的實例數、所占內存、類名。
3、進一步通過jmap獲取dump文件，也可以設置當內存溢出時自動生成dump文件
jmap -dump:format=b,file=heap <pid>，然后利用MAT工具等進行分析。
示例：
下設置JVM啟動參數：
-Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=F:/MAT/b.hprof
如下代碼，運行直到拋出OOM異常
public class DumpTest { static class OOMObject { private String name; public OOMObject(String name) { this.name = name; } } public static void main(String[] args) { List<OOMObject> list = new ArrayList<>(); while (true) { list.add(new OOMObject("內存測試")); } } }
然后使用MAT打開生成的b.phrof文件：
通過分析結果可以看到某一類對象占用內存的情況，從而可以定位到問題。
4、頻繁FGC分析
（1）FGC是什么時候觸發的？
下面4種情況，對象會進入到老年代中：
- YGC時，To Survivor區不足以存放存活的對象，對象會直接進入到老年代。
- 經過多次YGC后，如果存活對象的年齡達到了設定閾值，則會晉升到老年代中。
- 動態年齡判定規則，To Survivor區中相同年齡的對象，如果其大小之和占到了 To Survivor區一半以上的空間，那么大於此年齡的對象會直接進入老年代，而不需要達到默認的分代年齡。
- 大對象：由-XX:PretenureSizeThreshold啟動參數控制，若對象大小大於此值，就會繞過新生代, 直接在老年代中分配。
當晉升到老年代的對象大於了老年代的剩余空間時，就會觸發FGC（Major GC），FGC處理的區域同時包括新生代和老年代。除此之外，還有以下4種情況也會觸發FGC：
- 老年代的內存使用率達到了一定閾值（可通過參數調整），直接觸發FGC。
- 空間分配擔保：在YGC之前，會先檢查老年代最大可用的連續空間是否大於新生代所有對象的總空間。如果小於，說明YGC是不安全的，則會查看參數 HandlePromotionFailure 是否被設置成了允許擔保失敗，如果不允許則直接觸發Full GC；如果允許，那么會進一步檢查老年代最大可用的連續空間是否大於歷次晉升到老年代對象的平均大小，如果小於也會觸發 Full GC。
- Metaspace（元空間）在空間不足時會進行擴容，當擴容到了-XX:MetaspaceSize 參數的指定值時，也會觸發FGC。
- System.gc() 或者Runtime.gc() 被顯式調用時，觸發FGC。
（2） 在什么情況下，GC會對程序產生影響？
不管YGC還是FGC，都會造成一定程度的程序卡頓（即Stop The World問題：GC線程開始工作，其他工作線程被掛起），即使采用ParNew、CMS或者G1這些更先進的垃圾回收算法，也只是在減少卡頓時間，而並不能完全消除卡頓。
那到底什么情況下，GC會對程序產生影響呢？根據嚴重程度從高到底，我認為包括以下4種情況：
- FGC過於頻繁：FGC通常是比較慢的，少則幾百毫秒，多則幾秒，正常情況FGC每隔幾個小時甚至幾天才執行一次，對系統的影響還能接受。但是，一旦出現FGC頻繁（比如幾十分鍾就會執行一次），這種肯定是存在問題的，它會導致工作線程頻繁被停止，讓系統看起來一直有卡頓現象，也會使得程序的整體性能變差。
- YGC耗時過長：一般來說，YGC的總耗時在幾十或者上百毫秒是比較正常的，雖然會引起系統卡頓幾毫秒或者幾十毫秒，這種情況幾乎對用戶無感知，對程序的影響可以忽略不計。但是如果YGC耗時達到了1秒甚至幾秒（都快趕上FGC的耗時了），那卡頓時間就會增大，加上YGC本身比較頻繁，就會導致比較多的服務超時問題。
- FGC耗時過長：FGC耗時增加，卡頓時間也會隨之增加，尤其對於高並發服務，可能導致FGC期間比較多的超時問題，可用性降低，這種也需要關注。
- YGC過於頻繁：即使YGC不會引起服務超時，但是YGC過於頻繁也會降低服務的整體性能，對於高並發服務也是需要關注的。
其中，「FGC過於頻繁」和「YGC耗時過長」，這兩種情況屬於比較典型的GC問題，大概率會對程序的服務質量產生影響。剩余兩種情況的嚴重程度低一些，但是對於高並發或者高可用的程序也需要關注。
（3） 排查FGC問題的實踐指南
1. 清楚從程序角度，有哪些原因導致FGC？
- 大對象：系統一次性加載了過多數據到內存中（比如SQL查詢未做分頁），導致大對象進入了老年代。
- 內存泄漏：頻繁創建了大量對象，但是無法被回收（比如IO對象使用完后未調用close方法釋放資源），先引發FGC，最后導致OOM.
- 程序頻繁生成一些長生命周期的對象，當這些對象的存活年齡超過分代年齡時便會進入老年代，最后引發FGC. （即本文中的案例）
- 程序BUG導致動態生成了很多新類，使得 Metaspace 不斷被占用，先引發FGC，最后導致OOM.
- 代碼中顯式調用了gc方法，包括自己的代碼甚至框架中的代碼。
- JVM參數設置問題：包括總內存大小、新生代和老年代的大小、Eden區和S區的大小、元空間大小、垃圾回收算法等等。
2. 清楚排查問題時能使用哪些工具
- 公司的監控系統：大部分公司都會有，可全方位監控JVM的各項指標。
- JDK的自帶工具，包括jmap、jstat等常用命令：# 查看堆內存各區域的使用率以及GC情況jstat -gcutil -h20 pid 1000 # 查看堆內存中的存活對象，並按空間排序jmap -histo pid | head -n20 # dump堆內存文件jmap -dump:format=b,file=heap pid
- 可視化的堆內存分析工具：JVisualVM、MAT等
3. 排查指南
- 查看監控，以了解出現問題的時間點以及當前FGC的頻率（可對比正常情況看頻率是否正常）
- 了解該時間點之前有沒有程序上線、基礎組件升級等情況。
- 了解JVM的參數設置，包括：堆空間各個區域的大小設置，新生代和老年代分別采用了哪些垃圾收集器，然后分析JVM參數設置是否合理。
- 再對步驟1中列出的可能原因做排除法，其中元空間被打滿、內存泄漏、代碼顯式調用gc方法比較容易排查。
- 針對大對象或者長生命周期對象導致的FGC，可通過 jmap -histo 命令並結合dump堆內存文件作進一步分析，需要先定位到可疑對象。
- 通過可疑對象定位到具體代碼再次分析，這時候要結合GC原理和JVM參數設置，弄清楚可疑對象是否滿足了進入到老年代的條件才能下結論。
線程分析：
jstack -l <pid>