前言
測試同學反饋測試環境不能正常訪問，查看日誌發現OOM。雖然是測試環境，但是還是排查了一下原因，以免線上也出同樣的問題。
處理步驟
1、保留現場
首先使用jmap -heap pid查看堆空間使用情況，結果發現年輕代和老年代空間都滿了
還能看到的信息是JVM使用的垃圾收集器是Parallel Scavenge + Serial Old。
保留現場：
1.使用jmap -histo pid > 2020-02-21-erp-web.histo保留類的實例佔比統計信息；
2.使用jmap -dump:format=b,file=2020-02-21-erp-web.dump pid > 2020-02-21-erp-web.dump保留dump文件，這個很重要；
2、儘快恢復環境
1.堆內存確實配置的有點小了，才512M，調整JVM的堆最大最小內存爲1024M，-Xms=1024m -Xmx=1024m；
2.重啓程序；
3.雖然是測試環境，但是也有很多人在用，必須儘快恢復，若是線上環境更應如此。
3、分析dump文件，找到原因
3.1分析工具用什麼？
可選的工具有mat，jvisualvm，jhat，推薦用mat，jvisualvm勉強能看出點有用信息，但是遠遠不如mat好用，jhat真心覺得沒啥卵用。
3.2 下載mat
下載鏈接： https://www.eclipse.org/mat/downloads.php
下載後解壓即可運行
3.3 開始分析
3.3.1 先看看histo文件
先看下histo文件的前20行，看看有哪些類是項目中定義的，大概有個印象。
3.3.2 使用mat工具打開dump文件
File->Open File，選擇準備好的dump文件，稍微等待一會兒，分析需要一點時間，等待時間視dump文件大小而定，越大等的越久。
3.3.3 概述介紹
Histogram其實就是上面用jmap -histo導出的信息，所以直接看這裏也行，感嘆mat真香；
Leak Suspectes個人感覺最有用的存在，我主要也是從這裏去分析找問題原因；
Dominator Tree以樹的形式列出最大對象以及哪些對象引用的這些對象，比較有用，時間充裕時可以點開看看研究研究；
Top Consumers按類或包列出最“昂貴”的對象，其實也就是空間佔比最多的那些對象，也比較有用，時間充裕時可以點開看看研究研究；
其他的感覺用處就不大了。
3.3.3 Leak Suspects分析
可以看到mat分析認爲可能存在三個泄露疑點，其中疑點（a）佔堆內存的比例最大；
分析疑點1
mat分析出710個TaskThread實例佔用了159790952/1024/1024=152M的內存空間，但是僅從TaskThread這個類無法判斷出更有用的信息，好在mat細心的列出了佔內存最大的幾個實例，@0xe68bc3c0是實例的內存地址，然後下面又會介紹一個牛逼的工具：
點擊確定出現以下界面：
關注Retained Heap值比較大的項，但是不包括最大的那幾項，比如WebAppClassLoader，這個對象肯定大，但是這是看不出什麼信息的
找到一個比較大的項，發現這是mybatis當中的類，這時候大概能想到應該是查詢數據庫時一次性查了大量的數據，我們繼續往下看
發現確實如此，大量的ErpStaInfo對象存在，那這時候就該看看包路徑是mybaits的那些類了，爲了找到SQL語句，參數，以及mapperId等這些信息
可以看到這裏已經找到對應的mapper了
這裏找到了SQL和參數信息，選中bound sql右鍵go into：
選中sql右鍵copy->value可以複製SQL語句，參數也可以繼續右鍵go into查看，sql語句，參數，mapperId這些信息都已經拿到，到這裏我們基本已經定位到代碼位置了，剩下的看代碼邏輯找到原因就行了。
分析疑點2
按同樣的思路來，這個就比較簡單了，爲了節省篇幅，這裏只截圖重要的部分
這裏只找到了SQL語句和參數，沒有mapperId，但是發現SQL語句和疑點1是一樣的，其實就沒必要繼續分析了。
分析疑點3
堆中存在大量的字符串對象，這應該屬於正常現象，所以沒必要分析。
總結
通過這次的OOM分析，算是初步掌握了OOM分析的技能，但是還有更多的分析技能待學習，比如強大的OQL，掌握OQL絕對可以讓你的分析能力上升到一個新的高度，甚至都不用mat這樣的分析工具就能得到自己想要的信息，有時間再補一篇OQL的學習筆記吧，繼續加油。
雖然這次OOM只是在測試環境，不怎麼嚴重，但是一方面可以排除隱患，另一方面鍛鍊自己的事故分析能力，還是挺不錯的。
