JVM 心得 OOM時的堆信息獲取方法與分析

更新時間：2017年10月17日 09:36:54 作者：Michael_Chong

下面小編就為大家?guī)硪黄狫VM 心得 OOM時的堆信息獲取方法與分析。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

JVM的框架知識了解之后，實際的項目里發(fā)生了OOM異常的話，怎么獲取以及分析異常信息后怎么分析呢。

這里稍微做一下歸納。

第一步，首先通過下面兩個方法的任何一種，把發(fā)生OOM時的heap信息dump下來。

有兩個方法，通過設置可以把OOM時的dump信息獲取到：

1）方法1：在JVM的啟動參數(shù)里添加如下命令

-XX:+HeapDumpOnOutOfMemoryError

2）方法2：在JDK的安裝目錄下，找到bin目錄，然后雙擊執(zhí)行"jvisualvm.exe"

執(zhí)行程序之后，在視圖里可以看到正在執(zhí)行的java程序和Java線程ID（PID:xxx）。

右鍵選中"在OOM時生成dump"。

第二步，執(zhí)行如下代碼（本例使用方法1。如果使用方法2時需要先執(zhí)行代碼，再在JvirtualVM中選中java程序設置OOM時生成dump）：

代碼的意義是每一次創(chuàng)建一個1*1024*1024大小的int數(shù)組。在While中循環(huán)，引起Heap的OutOfMemory異常發(fā)生。

有一個小知識點共享下，map進行containsKey的處理時，key如果是javabean對象，判斷時使用的是對象的引用。所以每次判斷都是新的對象。

最好key的數(shù)據(jù)類型定義為值類型等（String作為key時使用常量字符串對String賦值如String key ="key"，不要用String key = new String(“key”)的形式，這樣又變成了一個引用對象了）。

package com.chong.studyparalell.jvm.heap;

import java.util.HashMap;
import java.util.Map;

public class HeapLeakage {

static class MapKey{
Integer key;
MapKey(Integer key){
this.key = key;
}
}

public static void main(String []args){

Map<MapKey,Integer[]> localMap = new HashMap();
while(true){
for(int i = 0;i<10;i++){
try{
Thread.sleep(100);
}catch(Exception e){
e.printStackTrace();
}
MapKey mapKey = new MapKey(new Integer(i));
if(!localMap.containsKey(mapKey)){
localMap.put(mapKey, new Integer[1*1024*1024]);
}
}
}
}
}

日志如下：

JAVAGENT: call premain instrumentation for class SizeOf
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid31512.hprof ...
Heap dump file created [491663234 bytes in 0.930 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.chong.studyparalell.jvm.heap.HeapLeakage.main(HeapLeakage.java:38)

第三步，在項目的classpath目錄下確認"java_pidXXX.hprof"文件是否存在，正常情況下應該存在的。

在jvirtualvm中，點擊"文件"->"裝入"->選中上述hprof文件。

點擊“類”tab頁，通過"大小"排序，可以看出java.lang.Integer占用了99%以上的空間。

雙擊這一行，可以進入進去看到，各個Integer的具體內容。這里的目的是發(fā)生OOM，所以Integer的內容沒有設值，進去可以發(fā)現(xiàn)值都是null。

那么實際的項目里，可以觀看發(fā)生問題線程里哪些對象的一直是活著的，并且size遠遠超出預期，重點分析這些可疑對象。推測的方向：是否在循環(huán)里大量的實例化對象，加載DB數(shù)據(jù)時一次加載了大量的數(shù)據(jù)，以及是否發(fā)生了內存泄露（如長生命周期的Map和Set，List中一直保存在大量的不再使用的對象引用。），以及靜態(tài)變量的使用等。

后記：

通過這幾天的JVM復習，以及OOM發(fā)生時的dump分析，再次做項目時，頭腦會更清晰一些。^-^
JVM告一段落了，接下來會發(fā)一些跟SpringBoot和Redis相關的學習心得。

您可能感興趣的文章: