序

最近頻繁收到線上報警，就看看到底啥原因

二 匯出dump檔案

2.1 查詢報警對應的程序

ps -ef|grep XX

是23898，看一下gc情況：

這才不到半小時，fgc就增加了好幾次。

jmap匯出dump。

jmap -dump:format=b,file=salary1 23898

因為檔案相對較大，幾百M。直接下載還是比較慢的，所以壓縮後下載是快的。

通常zip,tar壓縮後是原來的1/10.再大的也可以考慮bz2等別的格式。

三 分析dump

3.1 visualVM 

jdk 自帶的，可以去jdk安裝目錄下面直接開啟。

直觀的感受就是例項數裡面，AQS的node節點很多。下面的hashmap，ConcurrentHashMap也是值得關注的。

3.2 MAT

在用mat看看。

     1. Histogram可以列出記憶體中的物件，物件的個數以及大小。
     2. Dominator Tree可以列出那個執行緒，以及執行緒下面的那些物件佔用的空間。
     3.Top consumers通過圖形列出最大的object。
     4.Leak Suspects通過MA自動分析洩漏的原因。

因為是個web工程，所以，顯示web容器是懷疑的物件。

大量的是執行緒池的執行緒。

點進去看Histogram：

丟擲byte[],char[] 還是hashmap佔用的多。

搜一下程式碼看看。

作為一個web工程，典型的MVC應用。

存在大量的json返回介面，都是使用hashmap實現的。

開發的時候省點時間，實際上不推薦的，定義個對應的bean，fastjson 轉成對應的json就好。

效率也比這個好。

2. 在sso程式碼裡面。

 private final Map<Long, String> CITY_NAME = new ConcurrentHashMap<>();

類似這種，讀程式碼後沒有任何併發的情況，卻濫用了ConcurrentHashMap。

業務目的就是根據cityid獲取cityname.放到本地快取或者redis都行。

常見的模式就是：初始化根據sso介面獲取全部城市列表，放到快取，定時去更新就好，畢竟城市調整的機率小（業務發展新增開通城市）。

後續待業務小夥伴優化後看效果，待反饋。