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

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

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

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

這里稍微做一下歸納。

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

有兩個(gè)方法，通過設(shè)置可以把OOM時(shí)的dump信息獲取到：

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

-XX:+HeapDumpOnOutOfMemoryError

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

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

右鍵選中"在OOM時(shí)生成dump"。

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

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

有一個(gè)小知識(shí)點(diǎn)共享下，map進(jìn)行containsKey的處理時(shí)，key如果是javabean對(duì)象，判斷時(shí)使用的是對(duì)象的引用。所以每次判斷都是新的對(duì)象。

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

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)

第三步，在項(xiàng)目的classpath目錄下確認(rèn)"java_pidXXX.hprof"文件是否存在，正常情況下應(yīng)該存在的。

在jvirtualvm中，點(diǎn)擊"文件"->"裝入"->選中上述hprof文件。

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

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

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

后記：

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

您可能感興趣的文章: