聊聊怎么排查堆內存溢出
你知道的越多，你不知道的越多
上次給老公們說過了死循環cpu飆高的排查過程，今天就帶著老公們看看堆內存溢出我們一般怎么排查的。
- cpu100%排查文章
在排查之前，我想jvm的基礎知識大家應該都是了解了的吧?
老婆我就是不了解，人家要你說給我聽。
行行行，誒真實拿你們沒辦法，那我就帶大家回溫一下JVM的內存模型(這玩意跟JAVA內存模型JMM可不一樣，不要記錯了)
今天我就直說堆，因為溢出是發送在堆中的。
JVM堆內存被分為兩部分：年輕代(Young Generation)和老年代(Old Generation)。
年輕代年輕代是所有新對象產生的地方。當年輕代內存空間被用完時，就會觸發垃圾回收。這個垃圾回收叫做Minor GC。
年輕代
被分為3個部分——Enden區和兩個Survivor區。
年輕代空間的要點：
- 大多數新建的對象都位于Eden區。
- 當Eden區被對象填滿時，就會執行Minor GC，并把所有存活下來的對象轉移到其中一個survivor區。
- Minor GC同樣會檢查存活下來的對象，并把它們轉移到另一個survivor區。這樣在一段時間內，總會有一個空的survivor區。
- 經過多次GC周期后，仍然存活下來的對象會被轉移到年老代內存空間，通常這是在年輕代有資格提升到年老代前通過設定年齡閾值來完成的。
年老代
年老代內存里包含了長期存活的對象和經過多次Minor GC后依然存活下來的對象，通常會在老年代內存被占滿時進行垃圾回收。
GC種類
Major GC
老年代的垃圾收集叫做Major GC，Major GC通常是跟full GC是等價的，收集整個GC堆。
分代GC
- Young GC：只收集年輕代的GC
- Old GC：只收集年老代的GC(只有CMS的concurrent collection是這個模式)
- Mixed GC：收集整個young gen以及部分old gen的GC(只有G1有這個模式)
Full GC
Full GC定義是相對明確的，就是針對整個新生代、老生代、元空間(metaspace，java8以上版本取代perm gen)的全局范圍的GC。
老公們可以從上圖看到年輕代分為了一個Eden區和兩個survivor區(S1，S2)，survivor區同一時間只會有一個滿一個空，交替的。
然后就是GC到一定的閾值到老年代，今天不講永久代所以忽略Mataspace。
老婆：那怎么分析呢?
今天我就用一個JDK自帶的工具jvisualvm來給大家演示一波怎么操作的，因為這玩意誰都有，你去命令行敲一下jvisualvm就出來了(Mac是這樣的，不知道Windows是怎么樣子的)。
操作界面：
一般什么情況可能是出現了溢出呢?
超時，不進行服務，服務掛掉，接口不在服務這樣的異常問題。
那模擬也很簡單，我寫個循環一直往List丟數據，不使用list就能看到現象了
老公們可以看到圖形化界面還是很清晰明了的，這個是Visual GC的插件
大家點擊菜單欄的插件，然后安裝就好了，安裝完了記得點擊激活。
可以看到不釋放，堆空間就一直上去，直到OOM(out of memory)
這個時候我們就dump下來堆信息看看
會dump出一個這樣的hprof快照文件，可以用jvisualvm本身的系統去分析，我這里推薦MAT吧，因為我習慣這個了。
MAT ：下載地址
下來好了我們可以看到mat已經分析了我們的文件
你看他就是個暖男，都幫我們分析出來了一個問題，我們點進去看看
他發現了是ArrayList的問題了，我們再往下看看
看到了嘛，具體代碼的位置都幫我們定位好了，那排查也就是手到擒來的事情了。
延伸點
上面我們使用工具jump了，那怎么去服務器上jump呢?
- jmap -dump:format=b,file=<dumpfile.hprof> <pid>
有老公可能問了，不是所有的故障當時我們都在場的，無法及時jump，那也簡單
- -XX:+HeapDumpOnOutOfMemoryError
配置這玩意之后，oom的時候會自動jump的，到時候拿快照分析一波就好了。
MAT的功能還有很多的，百度谷歌太多工具文了，我就不做重復的工作了，比如還可以排查對象的強弱引用，還可以查看引用鏈等等。
還有個只寫這么點的原因是有點晚了，頂不住了，最近不拍視頻也是因為事情多了，有點小忙，希望老公們體量，對了Redis的分布式鎖已經在安排的路上了。
我是敖丙，一個在互聯網茍且偷生的工具人。
