快捷導(dǎo)航

實(shí)例解決Java異常之OutOfMemoryError的問題

更新時(shí)間：2019年02月04日 16:38:16 投稿：laozhang

在本篇文章中，我們給大家分享了關(guān)于解決Java異常之OutOfMemoryError的問題的方法，有此需要的朋友們學(xué)習(xí)下。

在Java虛擬機(jī)規(guī)范描述中，除了程序計(jì)數(shù)器外，虛擬機(jī)內(nèi)存的其他幾個(gè)運(yùn)行區(qū)域都有發(fā)生 OOM 異常的可能。在這里，用代碼驗(yàn)證各個(gè)運(yùn)行時(shí)區(qū)域存儲(chǔ)的內(nèi)容并討論該如何進(jìn)行處理。

Java堆溢出

Java 堆用于存儲(chǔ)對(duì)象實(shí)例，只要不斷創(chuàng)建對(duì)象，并且保證 GC Roots 到對(duì)象之間有可達(dá)路徑來(lái)避免垃圾回收機(jī)制清除這些對(duì)象，那么對(duì)象數(shù)量達(dá)到最大堆的容量限制之后就會(huì)產(chǎn)生內(nèi)存溢出異常。

異常再現(xiàn)

代碼采用如下虛擬機(jī)參數(shù)：

-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError

這樣 Java 堆的大小將被限制為20 MB 且不可拓展。通過參數(shù) -XX:+HeapDumpOnOutOfMemoryError 可以讓虛擬機(jī)在出現(xiàn)內(nèi)存溢出異常時(shí) Dump 出當(dāng)前的內(nèi)存堆轉(zhuǎn)儲(chǔ)快照以便時(shí)候進(jìn)行分析。

采用如下代碼進(jìn)行驗(yàn)證：

public class HeapOOM {

  static class OOMObject {

  }

  public static void main(String[] args) {

    List<OOMObject> list = new ArrayList<OOMObject>();

 

    while (true) {

      list.add(new OOMObject());

    }

  }

}

運(yùn)行結(jié)果：

java.lang.OutOfMemoryError: Java heap space

Dumping heap to java_pid3460.hprof ...

Heap dump file created [28199779 bytes in 0.237 secs]

解決方法

Java 堆內(nèi)存的 OOM 異常是實(shí)際應(yīng)用中常見的內(nèi)存溢出異常情況，出現(xiàn)時(shí)往往會(huì)緊跟著提示“Java heap space”。

要解決這個(gè)區(qū)域的異常，一般的手段是先通過內(nèi)存映像分析工具，比如 MAT ，確認(rèn)到底是出現(xiàn)了內(nèi)存泄漏還是內(nèi)存溢出。

如果是內(nèi)存泄漏，可以進(jìn)一步通過工具查看泄漏對(duì)象到 GC Roots 的引用鏈，找到泄漏對(duì)象是通過怎樣的途徑和 GC Roots 相關(guān)聯(lián)并導(dǎo)致垃圾收集器無(wú)法自動(dòng)回收它們所占的空間。

如果不是內(nèi)存泄漏，換而言之，內(nèi)存中的對(duì)象確實(shí)還有必要存活著，那么就應(yīng)當(dāng)檢查虛擬機(jī)的堆參數(shù)，與機(jī)器物理內(nèi)存對(duì)比看是否還可以調(diào)大。從代碼層面上看，是否存在某些對(duì)象生命周期過長(zhǎng)、持有狀態(tài)時(shí)間過長(zhǎng)的情況，嘗試減少程序運(yùn)行期間的內(nèi)存消耗。

虛擬機(jī)棧和本地方法棧溢出

由于在 HotSpot 虛擬機(jī)中并不區(qū)分虛擬機(jī)?；蛘弑镜胤椒?，因此對(duì)于 HotSpot 而言，雖然 -Xoss 參數(shù)存在，但是實(shí)際上是無(wú)效的，棧容量只由 -Xss 參數(shù)設(shè)定。

異常再現(xiàn)

在單線程下，代碼采用如下的虛擬機(jī)參數(shù)：

-Xss128k

使用該參數(shù)減小棧容量，使用如下代碼復(fù)現(xiàn)異常：

public class JavaVMStackSOF {

 

  private int stackLength = 1;

 

  public void stackLeak() {

    stackLength++;

    stackLeak();

  }

 

  public static void main(String[] args) throws Throwable {

    JavaVMStackSOF oom = new JavaVMStackSOF();

    try {

      oom.stackLeak();

    } catch (Throwable e) {

      System.out.println("stack length:" + oom.stackLength);

      throw e;

    }

  }

}

解決方法

如果使用虛擬機(jī)默認(rèn)參數(shù)，棧深度在大多數(shù)情況下（因?yàn)槊總€(gè)方法壓入棧的幀大小并不是一樣的，所以只能說在大多數(shù)情況下）達(dá)到1000 ~ 2000 完全沒有問題，對(duì)于正常的方法調(diào)用（包括遞歸），這個(gè)深度應(yīng)該完全足夠。

但是，如果是因?yàn)榻⑦^多的線程導(dǎo)致內(nèi)存溢出，在不能減少線程數(shù)或者更換64位虛擬機(jī)的情況下，就只能通過減少最大堆和減少棧容量來(lái)?yè)Q取更多的線程。

本機(jī)直接內(nèi)存溢出

DirectMemory 容量可以通過 -XX ：MaxDirectMemorySize 指定，如果不指定，則默認(rèn)與Java最大堆一樣。

異常再現(xiàn)

使用以下虛擬機(jī)參數(shù)：

-Xmx20M -XX:MaxDirectMemorySize=10M

使用以下代碼重現(xiàn)異常：

public class DirectMemoryOOM {

  private static final int _1MB = 1024 * 1024;

  public static void main(String[] args) throws Exception {

    Field unsafeField = Unsafe.class.getDeclaredFields()[0];

    unsafeField.setAccessible(true);

    Unsafe unsafe = (Unsafe) unsafeField.get(null);

    while (true) {

      unsafe.allocateMemory(_1MB);//直接申請(qǐng)分配內(nèi)存

    }

  }

}

解決方法

由 DirectMemory 導(dǎo)致的內(nèi)存溢出，一個(gè)明顯的特征就是在Heap Dump 文件中不會(huì)看見明顯的異常。

如果發(fā)現(xiàn) OOM 之后Dump文件很小，而程序中又直接或者間接使用了NIO ，那么就可以考慮檢查一下是不是這方面的原因。

以上就是我們整理的全部解決方法，感謝大家對(duì)腳本之家的支持。

您可能感興趣的文章: