一次使用 Eclipse Memory Analyzer 分析 Tomcat 記憶體溢出

標籤：調優

最近，線上生產系統突然頻繁的 JVM 記憶體警示！但本系統近期內並沒有上線改動！

為了能查清記憶體警示的原因，使用 Eclipse Memory Analyzer tool（MAT）對 JVM Dump 檔案進行了分析！

1. 產生 dump 檔案

用 jmap 生產 dump 檔案

jmap -dump:format=b,file=HeapDump.bin <pid>

2. MAT 安裝與介紹

：http://www.eclipse.org/mat/downloads.php

650) this.width=650;" src="http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180326.jpg" style="font-family:Simsun;font-size:14px;white-space:normal;background-color:rgb(255,255,255);" alt="1_20150209180326.jpg" />

通過 MAT 開啟 dump 出來的記憶體檔案，開啟後如：

650) this.width=650;" src="http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180332.jpg" style="font-family:Simsun;font-size:14px;white-space:normal;background-color:rgb(255,255,255);" alt="1_20150209180332.jpg" /> 650) this.width=650;" src="http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180338.jpg" style="font-family:Simsun;font-size:14px;white-space:normal;background-color:rgb(255,255,255);" alt="1_20150209180338.jpg" />

Histogram 可以列出記憶體中的對象，對象的個數以及大小。

Histogram 如：

Objects：類的對象的數量。
Shallow size：就是對象本身佔用記憶體的大小，不包含對其他對象的引用，也就是對象頭加成員變數（不是成員變數的值）的總和。
Retained size：是該對象自己的 shallow size，加上從該對象能直接或間接訪問到對象的 shallow size 之和。換句話說，retained size 是該對象被 GC 之後所能回收到記憶體的總和。

我們發現 ConcurrentHashMap 類的對象佔用了很多空間。

650) this.width=650;" src="http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180345.jpg" style="font-family:Simsun;font-size:14px;white-space:normal;background-color:rgb(255,255,255);" alt="1_20150209180345.jpg" />

Leak Suspects 如：

從那個餅圖，該圖深色地區被懷疑有記憶體流失，可以發現整個 heap 2G 記憶體，深色地區就佔了 98%。後面的描述，說明記憶體被一個執行個體佔用了大量記憶體，並指出 system class loader 載入的"java.util.concurrent.concurrentHashMap$Segmen[]"執行個體的記憶體中聚集（消耗空間），並建議用關鍵字"java.util.concurrent.concurrentHashMap$Segmen[]"進行檢查。所以，MAT 通過簡單的報告就說明了問題所在。

650) this.width=650;" src="http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180403.jpg" style="font-family:Simsun;font-size:14px;white-space:normal;background-color:rgb(255,255,255);" alt="1_20150209180403.jpg" />

Dominator Tree 如：>

我們逐層開啟 concurrentHashMap 的記憶體結構，發現 Key 非常多，並且最底層的 String 長度很大！

幸運的是該系統的下遊也是我們負責的系統，猜測 concurrentHashMap 應該是 RPC 調用返回回值待處理的記憶體儲存，正常情況這個 String 的長度不很大。仔細查看， String 裡包含了多了很多詳細的異常描述資訊，之前是沒有的。

650) this.width=650;" src="http://www.zhangsr.cn/resources/img/blog/attachment/201502/1_20150209180411.jpg" style="font-family:Simsun;font-size:14px;white-space:normal;background-color:rgb(255,255,255);" alt="1_20150209180411.jpg" />

排查下遊系統代碼，發現在返回異常時，與之前異常拋出有所不同：

try {} catch(Exception e) {    throw e;} ... try {} catch(Exception e) {    throw new Exception("xxxx", e);} // 返回虛擬碼response(e.getMessage);

就是有這些許的不同，我們看下原始碼：

public Throwable(String message, Throwable cause) {    fillInStackTrace();    detailMessage = message;    this.cause = cause;} public Throwable(Throwable cause) {    fillInStackTrace();    detailMessage = (cause==null ? null : cause.toString());    this.cause = cause;} public String getMessage() {    return detailMessage;}

當沒有 message，message = cause.toString()，所以就造成了返回大量不必要的異常資訊，從而影響了上遊系統！

參考：

http://tivan.iteye.com/blog/1487855

—————————— 本文同步發佈於 ZHANGSR 我的個人部落格  ——————————

本文出自 “十年一劍” 部落格，請務必保留此出處http://sauron.blog.51cto.com/5231038/1614362

一次使用 Eclipse Memory Analyzer 分析 Tomcat 記憶體溢出