概要

筆者所管理的測試一臺業務服務器，近期經常被反饋應用卡頓并且出現過多次內存溢出，本篇為對此問題的處理過程的記錄。
服務器環境采用Oracle JDK1.6，虛擬機為HosSpot，Web容器為Tomcat7。

處理過程

獲取堆內存轉儲快照

在用戶反饋系統卡頓時，登陸服務器通過命令查看內存使用情況

jps #獲取java的進程ID
jstat -gc 31795 #31795為jps查詢到的進程ID

得到內存使用情況如下：

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT   
932032.0 932032.0  0.0    0.0   932096.0 932096.0 5592448.0  5592448.0  131072.0 60017.9     20   13.991  69    892.270  906.260

從結果可以得知，堆內存已經達到容量上限，并且在不斷的進行FGC，所以應用系統表現的特別卡頓。
通過jmap命令生成堆轉儲快照：

jmap -dump:format=b,file=heap.hprof 31795

出現以下提示則表示生成成功：

Attaching to process ID 31795, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.45-b01
Dumping heap to heap.hprof ...
Heap dump file created

分析堆轉儲快照

使用MemoryAnalyzer打開堆轉儲快照，但提示heap space的堆內存溢出的異常：

An internal error occurred during: "Parsing heap dump from 'java_pid4259.hprof'".
Java heap space

修改配置MemoryAnalyzer.ini，調整堆內存大小

-Xms1024m
-Xmx8192m

在MAT的Leak Suspects中，可以看到很詳細的信息，有兩個對象占用了大量的內存。

通過查看線程信息發現為一個報表功能，該報表查詢的數據量太大，而且sql效率比較低。

優化思路

• 限制報表提取條件，盡量控制報表的大小在合理范圍內
• 超大的報表采用其他實現方式，例如通過定時任務將報表生成存放在指定文件服務器，由用戶自行下載
• 本例中的報表會由jdbc的ResultSet 轉成最終的報表對象，中間會經歷很多中間步驟，例如Vetcory、ArrayList等，盡量減少中間步驟
• 優化sql，盡快釋放對象，可以被GC進行回收