Java内存溢出(OOM)异常指南

时间 2019-11-18

标签 java 内存溢出 oom 异常指南栏目 Java 繁體版

原文原文链接

个人职业生涯中见过数以千计的内存溢出异常均与下文中的8种状况相关。本文分析什么状况会致使这些异常出现，提供示例代码的同时为您提供解决指南。
Nikita Salnikov-Tarnovski
Plumbr Co-Founder and VP of Engineering
本文内容来源于Plumbr，对原文内容有删减和补充java

这也许是目前最为完整的Java OOM异常的解决指南。mysql

一、`java.lang.OutOfMemoryError:Java heap space`

Java应用程序在启动时会指定所须要的内存大小，它被分割成两个不一样的区域：Heap space（堆空间）和Permgen（永久代）：linux

JVM内存模型示意图web

这两个区域的大小能够在JVM（Java虚拟机）启动时经过参数-Xmx和-XX:MaxPermSize设置，若是你没有显式设置，则将使用特定平台的默认值。算法

当应用程序试图向堆空间添加更多的数据，但堆却没有足够的空间来容纳这些数据时，将会触发java.lang.OutOfMemoryError: Java heap space异常。须要注意的是：即便有足够的物理内存可用，只要达到堆空间设置的大小限制，此异常仍然会被触发。sql

缘由分析

触发java.lang.OutOfMemoryError: Java heap space最多见的缘由就是应用程序须要的堆空间是XXL号的，可是JVM提供的倒是S号。解决方法也很简单，提供更大的堆空间便可。除了前面的因素还有更复杂的成因：数据库

流量/数据量峰值：应用程序在设计之初均有用户量和数据量的限制，某一时刻，当用户数量或数据量忽然达到一个峰值，而且这个峰值已经超过了设计之初预期的阈值，那么之前正常的功能将会中止，并触发java.lang.OutOfMemoryError: Java heap space异常。
内存泄漏：特定的编程错误会致使你的应用程序不停的消耗更多的内存，每次使用有内存泄漏风险的功能就会留下一些不能被回收的对象到堆空间中，随着时间的推移，泄漏的对象会消耗全部的堆空间，最终触发java.lang.OutOfMemoryError: Java heap space错误。

示例

①、简单示例编程

首先看一个很是简单的示例，下面的代码试图建立2 x 1024 x 1024个元素的整型数组，当你尝试编译并指定12M堆空间运行时（java -Xmx12m OOM）将会失败并抛出java.lang.OutOfMemoryError: Java heap space错误，而当你指定13M堆空间时，将正常的运行。数组

class OOM {
    static final int SIZE=2*1024*1024;
    public static void main(String[] a) {
        int[] i = new int[SIZE];
    }
}

运行以下：缓存

D:\>javac OOM.java
D:\>java -Xmx12m OOM
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at OOM.main(OOM.java:4)
D:\>java -Xmx13m OOM

②、内存泄漏示例

在Java中，当开发者建立一个新对象（好比：new Integer(5)）时，不须要本身开辟内存空间，而是把它交给JVM。在应用程序整个生命周期类，JVM负责检查哪些对象可用，哪些对象未被使用。未使用对象将被丢弃，其占用的内存也将被回收，这一过程被称为垃圾回收。JVM负责垃圾回收的模块集合被称为垃圾回收器（GC）。

Java的内存自动管理机制依赖于GC按期查找未使用对象并删除它们。Java中的内存泄漏是因为GC没法识别一些已经再也不使用的对象，而这些未使用的对象一直留在堆空间中，这种堆积最终会致使java.lang.OutOfMemoryError: Java heap space错误。

咱们能够很是容易的写出致使内存泄漏的Java代码：

public class KeylessEntry {
    
    static class Key {
        Integer id;
        
        Key(Integer id) {
            this.id = id;
        }
        
        @Override
        public int hashCode() {
            return id.hashCode();
        }
    }

    public static void main(String[] args) {
        Map<Key,String> m = new HashMap<Key,String>();
        while(true) {
            for(int i=0;i<10000;i++) {
                if(!m.containsKey(new Key(i))) {
                    m.put(new Key(i), "Number:" + i);
                }
            }
        }
    }
}

代码中HashMap为本地缓存，第一次while循环，会将10000个元素添加到缓存中。后面的while循环中，因为key已经存在于缓存中，缓存的大小将一直会维持在10000。但事实真的如此吗？因为Key实体没有实现equals()方法，致使for循环中每次执行m.containsKey(new Key(i))结果均为false，其结果就是HashMap中的元素将一直增长。

随着时间的推移，愈来愈多的Key对象进入堆空间且不能被垃圾收集器回收（m为局部变量，GC会认为这些对象一直可用，因此不会回收），直到全部的堆空间被占用，最后抛出java.lang.OutOfMemoryError:Java heap space。

上面的代码直接运行可能好久也不会抛出异常，能够在启动时使用-Xmx参数，设置堆内存大小，或者在for循环后打印HashMap的大小，执行后会发现HashMap的size一直再增加。

解决方法也很是简单，只要Key实现本身的equals方法便可：

Override
public boolean equals(Object o) {
    boolean response = false;
    if (o instanceof Key) {
        response = (((Key)o).id).equals(this.id);
    }
    return response;
}

解决方案

第一个解决方案是显而易见的，你应该确保有足够的堆空间来正常运行你的应用程序，在JVM的启动配置中增长以下配置：

-Xmx1024m

上面的配置分配1024M堆空间给你的应用程序，固然你也可使用其余单位，好比用G表示GB，K表示KB。下面的示例都表示最大堆空间为1GB：

java -Xmx1073741824 com.mycompany.MyClass
java -Xmx1048576k com.mycompany.MyClass
java -Xmx1024m com.mycompany.MyClass
java -Xmx1g com.mycompany.MyClass

而后，更多的时候，单纯地增长堆空间不能解决全部的问题。若是你的程序存在内存泄漏，一味的增长堆空间也只是推迟java.lang.OutOfMemoryError: Java heap space错误出现的时间而已，并未解决这个隐患。除此以外，垃圾收集器在GC时，应用程序会中止运行直到GC完成，而增长堆空间也会致使GC时间延长，进而影响程序的吞吐量。

若是你想彻底解决这个问题，那就好好提高本身的编程技能吧，固然运用好Debuggers, profilers, heap dump analyzers等工具，可让你的程序最大程度的避免内存泄漏问题。

二、`java.lang.OutOfMemoryError:GC overhead limit exceeded`

Java运行时环境（JRE）包含一个内置的垃圾回收进程，而在许多其余的编程语言中，开发者须要手动分配和释放内存。

Java应用程序只须要开发者分配内存，每当在内存中特定的空间再也不使用时，一个单独的垃圾收集进程会清空这些内存空间。垃圾收集器怎样检测内存中的某些空间再也不使用已经超出本文的范围，但你只须要相信GC能够作好这些工做便可。

默认状况下，当应用程序花费超过98%的时间用来作GC而且回收了不到2%的堆内存时，会抛出java.lang.OutOfMemoryError:GC overhead limit exceeded错误。具体的表现就是你的应用几乎耗尽全部可用内存，而且GC屡次均未能清理干净。

缘由分析

java.lang.OutOfMemoryError:GC overhead limit exceeded错误是一个信号，示意你的应用程序在垃圾收集上花费了太多时间但却没有什么卵用。默认超过98%的时间用来作GC却回收了不到2%的内存时将会抛出此错误。那若是没有此限制会发生什么呢？GC进程将被重启，100%的CPU将用于GC，而没有CPU资源用于其余正常的工做。若是一个工做原本只须要几毫秒便可完成，如今却须要几分钟才能完成，我想这种结果谁都没有办法接受。

因此java.lang.OutOfMemoryError:GC overhead limit exceeded也能够看作是一个fail-fast（快速失败）实战的实例。

示例

下面的代码初始化一个map并在无限循环中不停的添加键值对，运行后将会抛出GC overhead limit exceeded错误：

public class Wrapper {
    public static void main(String args[]) throws Exception {
        Map map = System.getProperties();
        Random r = new Random();
        while (true) {
            map.put(r.nextInt(), "value");
        }
    }
}

正如你所预料的那样，程序不能正常的结束，事实上，当咱们使用以下参数启动程序时：

java -Xmx100m -XX:+UseParallelGC Wrapper

咱们很快就能够看到程序抛出java.lang.OutOfMemoryError: GC overhead limit exceeded错误。但若是在启动时设置不一样的堆空间大小或者使用不一样的GC算法，好比这样：

java -Xmx10m -XX:+UseParallelGC Wrapper

咱们将看到以下错误：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Hashtable.rehash(Unknown Source)
    at java.util.Hashtable.addEntry(Unknown Source)
    at java.util.Hashtable.put(Unknown Source)
    at cn.moondev.Wrapper.main(Wrapper.java:12)

使用如下GC算法：-XX:+UseConcMarkSweepGC 或者-XX:+UseG1GC，启动命令以下：

java -Xmx100m -XX:+UseConcMarkSweepGC Wrapper
java -Xmx100m -XX:+UseG1GC Wrapper

获得的结果是这样的：

Exception: java.lang.OutOfMemoryError thrown from 
the UncaughtExceptionHandler in thread "main"

错误已经被默认的异常处理程序捕获，而且没有任何错误的堆栈信息输出。

以上这些变化能够说明，在资源有限的状况下，你根本没法没法预测你的应用是怎样挂掉的，何时会挂掉，因此在开发时，你不能仅仅保证本身的应用程序在特定的环境下正常运行。

解决方案

首先是一个毫无诚意的解决方案，若是你仅仅是不想看到java.lang.OutOfMemoryError:GC overhead limit exceeded的错误信息，能够在应用程序启动时添加以下JVM参数：

-XX:-UseGCOverheadLimit

可是强烈建议不要使用这个选项，由于这样并无解决任何问题，只是推迟了错误出现的时间，错误信息也变成了咱们更熟悉的java.lang.OutOfMemoryError: Java heap space而已。

另外一个解决方案，若是你的应用程序确实内存不足，增长堆内存会解决GC overhead limit问题，就以下面这样，给你的应用程序1G的堆内存：

java -Xmx1024m com.yourcompany.YourClass

但若是你想确保你已经解决了潜在的问题，而不是掩盖java.lang.OutOfMemoryError: GC overhead limit exceeded错误，那么你不该该仅止步于此。你要记得还有profilers和memory dump analyzers这些工具，你须要花费更多的时间和精力来查找问题。还有一点须要注意，这些工具在Java运行时有显著的开销，所以不建议在生产环境中使用。

三、`java.lang.OutOfMemoryError:Permgen space`

Java中堆空间是JVM管理的最大一块内存空间，能够在JVM启动时指定堆空间的大小，其中堆被划分红两个不一样的区域：新生代（Young）和老年代（Tenured），新生代又被划分为3个区域：Eden、From Survivor、To Survivor，以下图所示。

图片来源：并发编程网

java.lang.OutOfMemoryError: PermGen space错误就代表持久代所在区域的内存已被耗尽。

缘由分析

要理解java.lang.OutOfMemoryError: PermGen space出现的缘由，首先须要理解Permanent Generation Space的用处是什么。持久代主要存储的是每一个类的信息，好比：类加载器引用、运行时常量池（全部常量、字段引用、方法引用、属性）、字段(Field)数据、方法(Method)数据、方法代码、方法字节码等等。咱们能够推断出，PermGen的大小取决于被加载类的数量以及类的大小。

所以，咱们能够得出出现java.lang.OutOfMemoryError: PermGen space错误的缘由是：太多的类或者太大的类被加载到permanent generation（持久代）。

示例

①、最简单的示例

正如前面所描述的，PermGen的使用与加载到JVM类的数量有密切关系，下面是一个最简单的示例：

import javassist.ClassPool;
public class MicroGenerator {
    public static void main(String[] args) throws Exception {
        for (int i = 0; i < 100_000_000; i++) {
            generate("cn.moondev.User" + i);
        }
    }

    public static Class generate(String name) throws Exception {
        ClassPool pool = ClassPool.getDefault();
        return pool.makeClass(name).toClass();
    }
}

运行时请设置JVM参数：-XX:MaxPermSize=5m，值越小越好。须要注意的是JDK8已经彻底移除持久代空间，取而代之的是元空间（Metaspace），因此示例最好的JDK1.7或者1.6下运行。

代码在运行时不停的生成类并加载到持久代中，直到撑满持久代内存空间，最后抛出java.lang.OutOfMemoryError:Permgen space。代码中类的生成使用了javassist库。

②、Redeploy-time

更复杂和实际的一个例子就是Redeploy（从新部署，你能够想象一下你开发时，点击eclipse的reploy按钮或者使用idea时按ctrl + F5时的过程）。在从服务器卸载应用程序时，当前的classloader以及加载的class在没有实例引用的状况下，持久代的内存空间会被GC清理并回收。若是应用中有类的实例对当前的classloader的引用，那么Permgen区的class将没法被卸载，致使Permgen区的内存一直增长直到出现Permgen space错误。

不幸的是，许多第三方库以及糟糕的资源处理方式（好比：线程、JDBC驱动程序、文件系统句柄）使得卸载之前使用的类加载器变成了一件不可能的事。反过来就意味着在每次从新部署过程当中，应用程序全部的类的先前版本将仍然驻留在Permgen区中，你的每次部署都将生成几十甚至几百M的垃圾。

就以线程和JDBC驱动来讲说。不少人都会使用线程来处理一下周期性或者耗时较长的任务，这个时候必定要注意线程的生命周期问题，你须要确保线程不能比你的应用程序活得还长。不然，若是应用程序已经被卸载，线程还在继续运行，这个线程一般会维持对应用程序的classloader的引用，形成的结果就再也不多说。多说一句，开发者有责任处理好这个问题，特别是若是你是第三方库的提供者的话，必定要提供线程关闭接口来处理清理工做。

让咱们想象一个使用JDBC驱动程序链接到关系数据库的示例应用程序。当应用程序部署到服务器上的时：服务器建立一个classloader实例来加载应用全部的类（包含相应的JDBC驱动）。根据JDBC规范，JDBC驱动程序（好比：com.mysql.jdbc.Driver）会在初始化时将本身注册到java.sql.DriverManager中。该注册过程当中会将驱动程序的一个实例存储在DriverManager的静态字段内，代码能够参考：

// com.mysql.jdbc.Driver源码
package com.mysql.jdbc;

public class Driver extends NonRegisteringDriver implements java.sql.Driver {
    public Driver() throws SQLException {
    }
    static {
        try {
            DriverManager.registerDriver(new Driver());
        } catch (SQLException var1) {
            throw new RuntimeException("Can\'t register driver!");
        }
    }
}
// // // // // // // // // //
// 再看下DriverManager对应代码
private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();

public static synchronized void registerDriver(java.sql.Driver driver,DriverAction da) throws SQLException {
    if(driver != null) {
        registeredDrivers.addIfAbsent(new DriverInfo(driver, da));
    } else {
        throw new NullPointerException();
    }
}

如今，当从服务器上卸载应用程序的时候，java.sql.DriverManager仍将持有那个驱动程序的引用，进而持有用于加载应用程序的classloader的一个实例的引用。这个classloader如今仍然引用着应用程序的全部类。若是此程序启动时须要加载2000个类，占用约10MB永久代（PermGen）内存，那么只须要5~10次从新部署，就会将默认大小的永久代（PermGen）塞满，而后就会触发java.lang.OutOfMemoryError: PermGen space错误并崩溃。

解决方案

① 解决初始化时的OutOfMemoryError

当在应用程序启动期间触发因为PermGen耗尽引发的OutOfMemoryError时，解决方案很简单。应用程序须要更多的空间来加载全部的类到PermGen区域，因此咱们只须要增长它的大小。为此，请更改应用程序启动配置，并添加（或增长，若是存在）-XX：MaxPermSize参数，相似于如下示例：

java -XX:MaxPermSize=512m com.yourcompany.YourClass

② 解决Redeploy时的OutOfMemoryError

分析dump文件：首先，找出引用在哪里被持有；其次，给你的web应用程序添加一个关闭的hook，或者在应用程序卸载后移除引用。你可使用以下命令导出dump文件：

jmap -dump:format=b,file=dump.hprof <process-id>

若是是你本身代码的问题请及时修改，若是是第三方库，请试着搜索一下是否存在"关闭"接口，若是没有给开发者提交一个bug或者issue吧。

③ 解决运行时OutOfMemoryError

首先你须要检查是否容许GC从PermGen卸载类，JVM的标准配置至关保守，只要类一建立，即便已经没有实例引用它们，其仍将保留在内存中，特别是当应用程序须要动态建立大量的类但其生命周期并不长时，容许JVM卸载类对应用大有助益，你能够经过在启动脚本中添加如下配置参数来实现：

-XX:+CMSClassUnloadingEnabled

默认状况下，这个配置是未启用的，若是你启用它，GC将扫描PermGen区并清理已经再也不使用的类。但请注意，这个配置只在UseConcMarkSweepGC的状况下生效，若是你使用其余GC算法，好比：ParallelGC或者Serial GC时，这个配置无效。因此使用以上配置时，请配合：

-XX:+UseConcMarkSweepGC

若是你已经确保JVM能够卸载类，可是仍然出现内存溢出问题，那么你应该继续分析dump文件，使用如下命令生成dump文件：

jmap -dump:file=dump.hprof,format=b <process-id>

当你拿到生成的堆转储文件，并利用像Eclipse Memory Analyzer Toolkit这样的工具来寻找应该卸载却没被卸载的类加载器，而后对该类加载器加载的类进行排查，找到可疑对象，分析使用或者生成这些类的代码，查找产生问题的根源并解决它。

四、`java.lang.OutOfMemoryError:Metaspace`

前文已经提过，PermGen区域用于存储类的名称和字段，类的方法，方法的字节码，常量池，JIT优化等，但从Java8开始，Java中的内存模型发生了重大变化：引入了称为Metaspace的新内存区域，而删除了PermGen区域。请注意：不是简单的将PermGen区所存储的内容直接移到Metaspace区，PermGen区中的某些部分，已经移动到了普通堆里面。

OOM-example-metaspace，图片来源：Plumbr

缘由分析

Java8作出如此改变的缘由包括但不限于：

应用程序所须要的PermGen区大小很难预测，设置过小会触发PermGen OutOfMemoryError错误，过分设置致使资源浪费。
提高GC性能，在HotSpot中的每一个垃圾收集器须要专门的代码来处理存储在PermGen中的类的元数据信息。从PermGen分离类的元数据信息到Metaspace，因为Metaspace的分配具备和Java Heap相同的地址空间，所以Metaspace和Java Heap能够无缝的管理，并且简化了FullGC的过程，以致未来能够并行的对元数据信息进行垃圾收集，而没有GC暂停。
支持进一步优化，好比：G1并发类的卸载，也算为未来作准备吧

正如你所看到的，元空间大小的要求取决于加载的类的数量以及这种类声明的大小。因此很容易看到java.lang.OutOfMemoryError: Metaspace主要缘由：太多的类或太大的类加载到元空间。

示例

正如上文中所解释的，元空间的使用与加载到JVM中的类的数量密切相关。下面的代码是最简单的例子：

public class Metaspace {
    static javassist.ClassPool cp = javassist.ClassPool.getDefault();

    public static void main(String[] args) throws Exception{
        for (int i = 0; ; i++) { 
            Class c = cp.makeClass("eu.plumbr.demo.Generated" + i).toClass();
            System.out.println(i);
        }
    }
}

程序运行中不停的生成新类，全部的这些类的定义将被加载到Metaspace区，直到空间被彻底占用而且抛出java.lang.OutOfMemoryError:Metaspace。当使用-XX：MaxMetaspaceSize = 32m启动时，大约加载30000多个类时就会死机。

31023
31024
Exception in thread "main" javassist.CannotCompileException: by java.lang.OutOfMemoryError: Metaspace
    at javassist.ClassPool.toClass(ClassPool.java:1170)
    at javassist.ClassPool.toClass(ClassPool.java:1113)
    at javassist.ClassPool.toClass(ClassPool.java:1071)
    at javassist.CtClass.toClass(CtClass.java:1275)
    at cn.moondev.book.Metaspace.main(Metaspace.java:12)
    .....

解决方案

第一个解决方案是显而易见的，既然应用程序会耗尽内存中的Metaspace区空间，那么应该增长其大小，更改启动配置增长以下参数：

// 告诉JVM：Metaspace容许增加到512，而后才能抛出异常
-XX：MaxMetaspaceSize = 512m

另外一个方法就是删除此参数来彻底解除对Metaspace大小的限制（默认是没有限制的）。默认状况下，对于64位服务器端JVM，MetaspaceSize默认大小是21M（初始限制值），一旦达到这个限制值，FullGC将被触发进行类卸载，而且这个限制值将会被重置，新的限制值依赖于Metaspace的剩余容量。若是没有足够空间被释放，这个限制值将会上升，反之亦然。在技术上Metaspace的尺寸能够增加到交换空间，而这个时候本地内存分配将会失败（更具体的分析，能够参考：Java PermGen 去哪里了?）。

你能够经过修改各类启动参数来“快速修复”这些内存溢出错误，但你须要正确区分你是否只是推迟或者隐藏了java.lang.OutOfMemoryError的症状。若是你的应用程序确实存在内存泄漏或者原本就加载了一些不合理的类，那么全部这些配置都只是推迟问题出现的时间而已，实际也不会改善任何东西。

五、`java.lang.OutOfMemoryError:Unable to create new native thread`

一个思考线程的方法是将线程看着是执行任务的工人，若是你只有一个工人，那么他同时只能执行一项任务，但若是你有十几个工人，就能够同时完成你几个任务。就像这些工人都在物理世界，JVM中的线程完成本身的工做也是须要一些空间的，当有足够多的线程却没有那么多的空间时就会像这样：

图片来源：Plumbr

出现java.lang.OutOfMemoryError:Unable to create new native thread就意味着Java应用程序已达到其能够启动线程数量的极限了。

缘由分析

当JVM向OS请求建立一个新线程时，而OS却没法建立新的native线程时就会抛出Unable to create new native thread错误。一台服务器能够建立的线程数依赖于物理配置和平台，建议运行下文中的示例代码来测试找出这些限制。整体上来讲，抛出此错误会通过如下几个阶段：

运行在JVM内的应用程序请求建立一个新的线程
JVM向OS请求建立一个新的native线程
OS尝试建立一个新的native线程，这时须要分配内存给新的线程
OS拒绝分配内存给线程，由于32位Java进程已经耗尽内存地址空间（2-4GB内存地址已被命中）或者OS的虚拟内存已经彻底耗尽
Unable to create new native thread错误将被抛出

示例

下面的示例不能的建立并启动新的线程。当代码运行时，很快达到OS的线程数限制，并抛出Unable to create new native thread错误。

while(true){
    new Thread(new Runnable(){
        public void run() {
            try {
                Thread.sleep(10000000);
            } catch(InterruptedException e) { }        
        }    
    }).start();
}

解决方案

有时，你能够经过在OS级别增长线程数限制来绕过这个错误。若是你限制了JVM可在用户空间建立的线程数，那么你能够检查并增长这个限制：

// macOS 10.12上执行
$ ulimit -u
709

当你的应用程序产生成千上万的线程，并抛出此异常，表示你的程序已经出现了很严重的编程错误，我不以为应该经过修改参数来解决这个问题，无论是OS级别的参数仍是JVM启动参数。更可取的办法是分析你的应用是否真的须要建立如此多的线程来完成任务？是否可使用线程池或者说线程池的数量是否合适？是否能够更合理的拆分业务来实现.....

六、`java.lang.OutOfMemoryError:Out of swap space?`

Java应用程序在启动时会指定所须要的内存大小，能够经过-Xmx和其余相似的启动参数来指定。在JVM请求的总内存大于可用物理内存的状况下，操做系统会将内存中的数据交换到磁盘上去。

图片来源：plumbr

Out of swap space?表示交换空间也将耗尽，而且因为缺乏物理内存和交换空间，再次尝试分配内存也将失败。

缘由分析

当应用程序向JVM native heap请求分配内存失败而且native heap也即将耗尽时，JVM会抛出Out of swap space错误。该错误消息中包含分配失败的大小（以字节为单位）和请求失败的缘由。

Native Heap Memory是JVM内部使用的Memory，这部分的Memory能够经过JDK提供的JNI的方式去访问，这部分Memory效率很高，可是管理须要本身去作，若是没有把握最好不要使用，以防出现内存泄露问题。JVM 使用Native Heap Memory用来优化代码载入（JTI代码生成），临时对象空间申请，以及JVM内部的一些操做。

这个问题每每发生在Java进程已经开始交换的状况下，现代的GC算法已经作得足够好了，当时当面临因为交换引发的延迟问题时，GC暂停的时间每每会让大多数应用程序不能容忍。

java.lang.OutOfMemoryError:Out of swap space?每每是由操做系统级别的问题引发的，例如：

操做系统配置的交换空间不足。
系统上的另外一个进程消耗全部内存资源。

还有多是本地内存泄漏致使应用程序失败，好比：应用程序调用了native code连续分配内存，但却没有被释放。

解决方案

解决这个问题有几个办法，一般最简单的方法就是增长交换空间，不一样平台实现的方式会有所不一样，好比在Linux下能够经过以下命令实现：

# 原做者使用，因为我手里并无Linux环境，因此并未测试
# 建立并附加一个大小为640MB的新交换文件
swapoff -a 
dd if=/dev/zero of=swapfile bs=1024 count=655360
mkswap swapfile
swapon swapfile

Java GC会扫描内存中的数据，若是是对交换空间运行垃圾回收算法会使GC暂停的时间增长几个数量级，所以你应该慎重考虑使用上文增长交换空间的方法。

若是你的应用程序部署在JVM须要同其余进程激烈竞争获取资源的物理机上，建议将服务隔离到单独的虚拟机中

但在许多状况下，您惟一真正可行的替代方案是：

升级机器以包含更多内存
优化应用程序以减小其内存占用

当您转向优化路径时，使用内存转储分析程序来检测内存中的大分配是一个好的开始。

七、`java.lang.OutOfMemoryError:Requested array size exceeds VM limit`

Java对应用程序能够分配的最大数组大小有限制。不一样平台限制有所不一样，但一般在1到21亿个元素之间。

图片来源：plumbr

当你遇到Requested array size exceeds VM limit错误时，意味着你的应用程序试图分配大于Java虚拟机能够支持的数组。

缘由分析

该错误由JVM中的native code抛出。 JVM在为数组分配内存以前，会执行特定于平台的检查：分配的数据结构是否在此平台中是可寻址的。

你不多见到这个错误是由于Java数组的索引是int类型。 Java中的最大正整数为2 ^ 31 - 1 = 2,147,483,647。而且平台特定的限制能够很是接近这个数字，例如：个人环境上(64位macOS，运行Jdk1.8)能够初始化数组的长度高达2,147,483,645（Integer.MAX_VALUE-2）。若是再将数组的长度增长1到Integer.MAX_VALUE-1会致使熟悉的OutOfMemoryError：

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit

可是，在使用OpenJDK 6的32位Linux上，在分配具备大约11亿个元素的数组时，您将遇到Requested array size exceeded VM limit的错误。要理解你的特定环境的限制，运行下文中描述的小测试程序。

示例

for (int i = 3; i >= 0; i--) {
    try {
        int[] arr = new int[Integer.MAX_VALUE-i];
        System.out.format("Successfully initialized an array with %,d elements.\n", Integer.MAX_VALUE-i);
    } catch (Throwable t) {
        t.printStackTrace();
    }
}

该示例重复四次，并在每一个回合中初始化一个长原语数组。该程序尝试初始化的数组的大小在每次迭代时增长1，最终达到Integer.MAX_VALUE。如今，当使用Hotspot 7在64位Mac OS X上启动代码片断时，应该获得相似于如下内容的输出：

java.lang.OutOfMemoryError: Java heap space
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Java heap space
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)

注意，在出现Requested array size exceeded VM limit以前，出现了更熟悉的java.lang.OutOfMemoryError: Java heap space。这是由于初始化2 ^ 31-1个元素的数组须要腾出8G的内存空间，大于JVM使用的默认值。

解决方案

java.lang.OutOfMemoryError:Requested array size exceeds VM limit可能会在如下任一状况下出现：

数组增加太大，最终大小在平台限制和Integer.MAX_INT之间
你有意分配大于2 ^ 31-1个元素的数组

在第一种状况下，检查你的代码库，看看你是否真的须要这么大的数组。也许你能够减小数组的大小，或者将数组分红更小的数据块，而后分批处理数据。

在第二种状况下，记住Java数组是由int索引的。所以，当在平台中使用标准数据结构时，数组不能超过2 ^ 31-1个元素。事实上，在编译时就会出错：error：integer number too large。

八、`Out of memory:Kill process or sacrifice child`

为了理解这个错误，咱们须要补充一点操做系统的基础知识。操做系统是创建在进程的概念之上，这些进程在内核中做业，其中有一个很是特殊的进程，名叫“内存杀手（Out of memory killer）”。当内核检测到系统内存不足时，OOM killer被激活，而后选择一个进程杀掉。哪个进程这么倒霉呢？选择的算法和想法都很朴实：谁占用内存最多，谁就被干掉。若是你对OOM Killer感兴趣的话，建议你阅读参考资料2中的文章。

OOM Killer，图片来源：plumbr

当可用虚拟虚拟内存(包括交换空间)消耗到让整个操做系统面临风险时，就会产生Out of memory:Kill process or sacrifice child错误。在这种状况下，OOM Killer会选择“流氓进程”并杀死它。

缘由分析

默认状况下，Linux内核容许进程请求比系统中可用内存更多的内存，但大多数进程实际上并无使用完他们所分配的内存。这就跟现实生活中的宽带运营商相似，他们向全部消费者出售一个100M的带宽，远远超过用户实际使用的带宽，一个10G的链路能够很是轻松的服务100个(10G/100M)用户，但实际上宽带运行商每每会把10G链路用于服务150人或者更多，以便让链路的利用率更高，毕竟空闲在那儿也没什么意义。

Linux内核采用的机制跟宽带运营商差很少，通常状况下都没有问题，但当大多数应用程序都消耗完本身的内存时，麻烦就来了，由于这些应用程序的内存需求加起来超出了物理内存（包括 swap）的容量，内核（OOM killer）必须杀掉一些进程才能腾出空间保障系统正常运行。就如同上面的例子中，若是150人都占用100M的带宽，那么总的带宽确定超过了10G这条链路能承受的范围。

示例

当你在Linux上运行以下代码：

public static void main(String[] args){
    List<int[]> l = new java.util.ArrayList();
    for (int i = 10000; i < 100000; i++) {
        try {
            l.add(new int[100000000]);
        } catch (Throwable t) {
            t.printStackTrace();
        }
    }
}

在Linux的系统日志中/var/log/kern.log会出现如下日志：

Jun  4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child
Jun  4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB

注意：你可能须要调整交换文件和堆大小，不然你将很快见到熟悉的Java heap space异常。在原做者的测试用例中，使用-Xmx2g指定的2g堆，并具备如下交换配置：

# 注意：原做者使用，因为我手里并无Linux环境，因此并未测试
swapoff -a 
dd if=/dev/zero of=swapfile bs=1024 count=655360
mkswap swapfile
swapon swapfile

解决方案

解决这个问题最有效也是最直接的方法就是升级内存，其余方法诸如：调整OOM Killer配置、水平扩展应用，将内存的负载分摊到若干小实例上..... 咱们不建议的作法是增长交换空间，具体缘由已经在前文说过。参考资料②中详细的介绍了怎样微调OOM Killer配置以及OOM Killer选择进程算法的实现，建议你参考阅读。

参考资料：

① 想要了解更多PermGen与Metaspace的内容推荐你阅读：

② 若是你对OOM Killer感兴趣的话，强烈建议你阅读这篇文章：

理解和配置 Linux 下的 OOM Killer

做者：CHEN川连接：https://www.jianshu.com/p/2fdee831ed03

Java内存溢出(OOM)异常指南

一、java.lang.OutOfMemoryError:Java heap space

缘由分析

示例

解决方案

二、java.lang.OutOfMemoryError:GC overhead limit exceeded

缘由分析

示例

解决方案

三、java.lang.OutOfMemoryError:Permgen space

缘由分析

示例

解决方案

四、java.lang.OutOfMemoryError:Metaspace

缘由分析

示例

解决方案

五、java.lang.OutOfMemoryError:Unable to create new native thread

缘由分析

示例

解决方案

六、java.lang.OutOfMemoryError:Out of swap space?

缘由分析

解决方案

七、java.lang.OutOfMemoryError:Requested array size exceeds VM limit

缘由分析

示例

解决方案

八、Out of memory:Kill process or sacrifice child

缘由分析

示例

解决方案

参考资料：

一、`java.lang.OutOfMemoryError:Java heap space`

二、`java.lang.OutOfMemoryError:GC overhead limit exceeded`

三、`java.lang.OutOfMemoryError:Permgen space`

四、`java.lang.OutOfMemoryError:Metaspace`

五、`java.lang.OutOfMemoryError:Unable to create new native thread`

六、`java.lang.OutOfMemoryError:Out of swap space?`

七、`java.lang.OutOfMemoryError:Requested array size exceeds VM limit`

八、`Out of memory:Kill process or sacrifice child`