深刻理解JVM - 內存溢出實戰

時間  2020-01-04
標籤 深刻 理解 jvm 內存 溢出 實戰 欄目 Java 简体版
原文   原文鏈接

Java堆溢出

Java堆用於存儲對象實例，只要不斷地建立對象，當對象數量到達最大堆的容量限制後就會產生內存溢出異常。最多見的內存溢出就是存在大的容器，而無法回收，好比：Map，List等。java

出現下面信息就能夠判定出現了堆內存溢出。git

java.lang.OutOfMemoryError: Java heap space

保證GC Roots到對象之間有可達路徑來避免垃圾回收機制清除這些對象github

示例
設置JVM內存參數：spring

-verbose:gc -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump
/**
 * java 堆內存溢出
 * <p>
 * VM Args: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump
 *
 * @author yuhao.wang3
 * @since 2019/11/30 17:09
 */
public class HeapOutOfMemoryErrorTest {
    public static void main(String[] args) throws InterruptedException {
        // 模擬大容器
        List<Object> list = Lists.newArrayList();
        for (long i = 1; i > 0; i++) {
            list.add(new Object());
            if (i % 100_000 == 0) {
                System.out.println(Thread.currentThread().getName() + "::" + i);
            }
        }
    }
}

運行結果jvm

[GC (Allocation Failure)  5596K->1589K(19968K), 0.0422027 secs]
main::100000
main::200000
[GC (Allocation Failure)  7221K->5476K(19968K), 0.0144103 secs]
main::300000
[GC (Allocation Failure)  9190K->9195K(19968K), 0.0098252 secs]
main::400000
main::500000
[Full GC (Ergonomics)  17992K->13471K(19968K), 0.3431052 secs]
main::600000
main::700000
main::800000
[Full GC (Ergonomics)  17127K->16788K(19968K), 0.1581969 secs]
[Full GC (Allocation Failure)  16788K->16758K(19968K), 0.1994445 secs]
java.lang.OutOfMemoryError: Java heap space
Dumping heap to D:\dump\java_pid7432.hprof ...
Heap dump file created [28774262 bytes in 0.221 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3210)
    at java.util.Arrays.copyOf(Arrays.java:3181)
    at java.util.ArrayList.grow(ArrayList.java:261)
    at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
    at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
    at java.util.ArrayList.add(ArrayList.java:458)
    at com.xiaolyuh.HeapOutOfMemoryErrorTest.main(HeapOutOfMemoryErrorTest.java:23)
Disconnected from the target VM, address: '127.0.0.1:61622', transport: 'socket'

分析工具

JDK自帶的jvisualvm.exe工具能夠分析.hprof和.dump文件。socket

首先須要找出最大的對象，判斷最大對象的存在是否合理，如何合理就須要調整JVM內存大小。若是不合理，那麼這個對象的存在，就是最有多是引發內存溢出的根源。經過GC Roots的引用鏈信息，就能夠比較準確地定位出泄露代碼的位置。ide

  1. 查詢最大對象

up-601558c8ddac2e7c92b10debf904ac811b7.png

2.找出具體的對象
up-23d46b99308e12c6a958bd5710b148cc28b.pngspring-boot

解決方案

1.優化代碼，去除大對象；
2.調整JVM內存大小（-Xmx與-Xms）；工具

超出GC開銷限制

當出現java.lang.OutOfMemoryError: GC overhead limit exceeded異常信息時，表示超出了GC開銷限制。當超過98%的時間用來作GC，可是卻回收了不到2%的堆內存時會拋出此異常。測試

異常棧

[Full GC (Ergonomics)  19225K->19225K(19968K), 0.1044070 secs]
[Full GC (Ergonomics)  19227K->19227K(19968K), 0.0684710 secs]
java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to D:\dump\java_pid17556.hprof ...
Heap dump file created [34925385 bytes in 0.132 secs]
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
[Full GC (Ergonomics)  19257K->933K(19968K), 0.0403569 secs]
    at com.xiaolyuh.HeapOutOfMemoryErrorTest.main(HeapOutOfMemoryErrorTest.java:25)
ERROR: JDWP Unable to get JNI 1.2 environment, jvm->GetEnv() return code = -2
JDWP exit error AGENT_ERROR_NO_JNI_ENV(183):  [util.c:840]

解決方案

1.經過-XX:-UseGCOverheadLimit參數來禁用這個檢查，可是並不能從根本上來解決內存溢出的問題，最後仍是會報出java.lang.OutOfMemoryError: Java heap space異常；
2.調整JVM內存大小（-Xmx與-Xms）；

虛擬機棧和本地方法棧溢出

  • 若是線程請求的棧深度大於虛擬機所容許的最大深度，將拋出StackOverflowError異常。
  • 若是虛擬機在擴展棧時沒法申請到足夠的內存空間，則拋出OutOfMemoryError異常。

這裏把異常分紅兩種狀況，看似更加嚴謹，但卻存在着一些互相重疊的地方：當棧空間沒法繼續分配時，究竟是內存過小，仍是已使用的棧空間太大，其本質上只是對同一件事情的兩種描述而已。

StackOverflowError

出現StackOverflowError異常的主要緣由有兩點：

  • 單個線程請求的棧深度大於虛擬機所容許的最大深度
  • 建立的線程過多

單個線程請求的棧深度過大

單個線程請求的棧深度大於虛擬機所容許的最大深度，主要表現有如下幾點：

  1. 存在遞歸調用
  2. 存在循環依賴調用
  3. 方法調用鏈路很深，好比使用裝飾器模式的時候，對已經裝飾後的對象再進行裝飾

異常信息java.lang.StackOverflowError。

裝飾器示例：

Collections.unmodifiableList(
        Collections.unmodifiableList(
                Collections.unmodifiableList(
                        Collections.unmodifiableList(
                                Collections.unmodifiableList(
                                                        ...)))))));

遞歸示例：

/**
 * java 虛擬機棧和本地方法棧內存溢出測試
 * <p>
 * VM Args: -Xss128k
 *
 * @author yuhao.wang3
 * @since 2019/11/30 17:09
 */
public class StackOverflowErrorErrorTest {
    private int stackLength = 0;

    public void stackLeak() {
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) {
        StackOverflowErrorErrorTest sof = new StackOverflowErrorErrorTest();
        try {
            sof.stackLeak();
        } catch (Exception e) {
            System.out.println(sof.stackLength);
            e.printStackTrace();
        }
    }
}

運行結果：

stackLength::1372
java.lang.StackOverflowError
    at com.xiaolyuh.StackOverflowErrorErrorTest.stackLeak(StackOverflowErrorErrorTest.java:16)
    at com.xiaolyuh.StackOverflowErrorErrorTest.stackLeak(StackOverflowErrorErrorTest.java:16)
    at com.xiaolyuh.StackOverflowErrorErrorTest.stackLeak(StackOverflowErrorErrorTest.java:16)
...

當增大棧空間的時候咱們就會發現，遞歸深度會增長，修改棧空間-Xss1m，而後運行程序，運行結果以下：

stackLength::20641
java.lang.StackOverflowError
    at com.xiaolyuh.StackOverflowErrorErrorTest.stackLeak(StackOverflowErrorErrorTest.java:16)
    at com.xiaolyuh.StackOverflowErrorErrorTest.stackLeak(StackOverflowErrorErrorTest.java:16)
...

修改遞歸方法的參數列表後遞歸深度急劇減小：

public void stackLeak(String ags1, String ags2, String ags3) {
    stackLength++;
    stackLeak(ags1, ags2, ags3);
}

運行結果以下：

stackLength::13154
java.lang.StackOverflowError
    at com.xiaolyuh.StackOverflowErrorErrorTest.stackLeak(StackOverflowErrorErrorTest.java:16)
    at com.xiaolyuh.StackOverflowErrorErrorTest.stackLeak(StackOverflowErrorErrorTest.java:16)
...

因而可知影響遞歸的深度因素有：

  1. 單個線程的棧空間大小（-Xss）
  2. 局部變量表的大小
單個線程請求的棧深度超過內存限制致使的棧內存溢出，通常是因爲非正確的編碼致使的。從上面的示例咱們能夠看出，當棧空間在-Xss128k的時候，調用層級都在1000以上，通常狀況下方法的調用是達不到這個深度的。若是方法調用的深度確實有這麼大，那麼咱們能夠經過-Xss配置來增大棧空間大小。

建立的線程過多

不斷地創建線程也可能致使棧內存溢出，由於咱們機器的總內存是有限制的，因此虛擬機棧和本地方法棧對應的內存也是有最大限制的。若是單個線程的棧空間越大，那麼整個應用容許建立的線程數就越少。異常信息java.lang.OutOfMemoryError: unable to create new native thread。

虛擬機棧和本地方法棧內存 ≈ 操做系統內存限制 - 最大堆容量(Xmx) - 最大方法區容量(MaxPermSize)
過多建立線程示例：

/**
 * java 虛擬機棧和本地方法棧內存溢出測試
 * <p>
 * 建立線程過多致使內存溢出異常
 * <p>
 * VM Args: -verbose:gc -Xss20M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump
 *
 * @author yuhao.wang3
 * @since 2019/11/30 17:09
 */
public class StackOutOfMemoryErrorTest {
    private static int threadCount;

    public static void main(String[] args) throws Throwable {
        try {
            while (true) {
                threadCount++;
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        try {
                            Thread.sleep(1000 * 60 * 10);
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                    }
                }).start();
            }
        } catch (Throwable e) {
            e.printStackTrace();
            throw e;
        } finally {
            System.out.println("threadCount=" + threadCount);
        }
    }
}

Java的線程是映射到操做系統的內核線程上，所以上述代碼執行時有較大的風險，可能會致使操做系統假死。

運行結果：

java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Thread.java:717)
    at StackOutOfMemoryErrorTest.main(StackOutOfMemoryErrorTest.java:17)
threadCount=4131
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Thread.java:717)
    at StackOutOfMemoryErrorTest.main(StackOutOfMemoryErrorTest.java:17)

須要從新上述異常，最好是在32位機器上，由於我在64位機器沒有重現。

在有限的內存空間裏面，當咱們須要建立更多的線程的時候，咱們能夠減小單個線程的棧空間大小。

元數據區域的內存溢出
元數據區域或方法區是用於存放Class的相關信息，如類名、訪問修飾符、常量池、字段描述、方法描述等。咱們能夠經過在運行時產生大量的類去填滿方法區，直到溢出，如：代理的使用(CGlib)、大量JSP或動態產生JSP文件的應用（JSP第一次運行時須要編譯爲Java類）、基於OSGi的應用（即便是同一個類文件，被不一樣的加載器加載也會視爲不一樣的類）等。

/**
 * java 元數據區域/方法區的內存溢出
 * <p>
 * VM Args JDK 1.6: set JAVA_OPTS=-verbose:gc -XX:PermSize=10m -XX:MaxPermSize=10m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump
 * <p>
 * VM Args JDK 1.8: set JAVA_OPTS=-verbose:gc -Xmx20m -XX:MetaspaceSize=5m -XX:MaxMetaspaceSize=5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump
 *
 * @author yuhao.wang3
 * @since 2019/11/30 17:09
 */
public class MethodAreaOutOfMemoryErrorTest {

    static class MethodAreaOOM {
    }

    public static void main(String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(MethodAreaOOM.class);
            enhancer.setCallback(new MethodInterceptor() {
                @Override
                public Object intercept(Object obj, Method method, Object[] params, MethodProxy proxy) throws Throwable {
                    return proxy.invokeSuper(obj, params);
                }
            });
            enhancer.create();
        }
    }
}

運行結果：

[GC (Last ditch collection)  1283K->1283K(16384K), 0.0002585 secs]
[Full GC (Last ditch collection)  1283K->1226K(19968K), 0.0075856 secs]
java.lang.OutOfMemoryError: Metaspace
Dumping heap to D:\dump\java_pid18364.hprof ...
Heap dump file created [2479477 bytes in 0.015 secs]
[GC (Metadata GC Threshold)  1450K->1354K(19968K), 0.0003906 secs]
[Full GC (Metadata GC Threshold)  1354K->976K(19968K), 0.0073752 secs]
[GC (Last ditch collection)  976K->976K(19968K), 0.0002921 secs]
[Full GC (Last ditch collection)  976K->973K(19968K), 0.0045243 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:52)
    at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
    at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
    at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291)
    at org.springframework.cglib.core.KeyFactory$Generator.create(KeyFactory.java:221)
    at org.springframework.cglib.core.KeyFactory.create(KeyFactory.java:174)
    at org.springframework.cglib.core.KeyFactory.create(KeyFactory.java:153)
    at org.springframework.cglib.proxy.Enhancer.<clinit>(Enhancer.java:73)
    at com.xiaolyuh.MethodAreaOutOfMemoryErrorTest.main(MethodAreaOutOfMemoryErrorTest.java:26)

運行時常量池的內存溢出
String.intern()是一個Native方法，它的做用是：若是字符串常量池中已經包含一個等於此String對象的字符串，則返回表明池中這個字符串的String對象；不然，將此String對象包含的字符串添加到常量池中，而且返回此String對象的引用。

在JDK 1.6的時候，運行時常量池是在方法區中，因此直接限制了方法區中大小就能夠模擬出運行池常量池的內存溢出。

/**
 * java 方法區和運行時常量池溢出
 * <p>
 * VM Args JDK 1.6: set JAVA_OPTS=-verbose:gc -XX:PermSize10 -XX:MaxPermSize10m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump
 *
 * @author yuhao.wang3
 * @since 2019/11/30 17:09
 */
public class RuntimeConstantOutOfMemoryErrorTest {

    public static void main(String[] args) {
        // 使用List保存着常量池的引用，避免Full GC 回收常量池行爲
        List<String> list = new ArrayList<>();
        for (int i = 0; ; i++) {
            list.add(String.valueOf(i).intern());
        }
    }
}

運行結果：

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
    at java.lang.String.intern(Native Method)
    at RuntimeConstantOutOfMemoryErrorTest.main(RuntimeConstantOutOfMemoryErrorTest.java:18)

直接內存溢出

DirectMemory容量可經過-XX:MaxDirectMemorySize指定，若是不指定，則默認與Java堆最大值（-Xmx指定）同樣。

/**
 * java 直接內存溢出
 * <p>
 * VM Args JDK 1.6: set JAVA_OPTS=-verbose:gc -Xms20m -XX:MaxDirectMemorySize=10m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\dump
 *
 * @author yuhao.wang3
 * @since 2019/11/30 17:09
 */
public class DirectMemoryOutOfMemoryErrorTest {

    public static void main(String[] args) throws IllegalAccessException {
        int _1M = 1024 * 1024;
        Field unsafeField = Unsafe.class.getDeclaredFields()[0];
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe) unsafeField.get(null);
        while (true) {
            unsafe.allocateMemory(_1M);
        }
    }
}

運行結果：

Exception in thread "main" java.lang.OutOfMemoryError
    at sun.misc.Unsafe.allocateMemory(Native Method)
    at com.xiaolyuh.DirectMemoryOutOfMemoryErrorTest.main(DirectMemoryOutOfMemoryErrorTest.java:23)

由DirectMemory致使的內存溢出，一個明顯的特徵是在Heap Dump文件中不會看見明顯的異常，若是讀者發現OOM以後Dump文件很小，而程序中又直接或間接使用了NIO，那就能夠考慮檢查一下是否是這方面的緣由。

解決方案

經過-XX:MaxDirectMemorySize指定直接內存大小。

源碼

https://github.com/wyh-spring...

spring-boot-student-jvm工程

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程