OMM Error和七大垃圾回收器详解

作者: Minority | 来源:发表于2020-03-09 19:00 被阅读0次

转载请注明出处：https://www.jianshu.com/p/ba415aa2330b

OutOfMemoryError

Case1： StackOverflowError

栈满会抛出该错误。无限递归就会导致StackOverflowError，是java.lang.Throwable→java.lang.Error→java.lang.VirtualMachineError下的错误。

public class Test {

    public static void main(String[] args) {
        stackOverFlowError();
    }

    private static void stackOverFlowError() {
        stackOverFlowError();
    }

}
/*====================output========================
Exception in thread "main" java.lang.StackOverflowError
 */

Case2：OOM—Java heap space

堆满会抛出该错误——堆内存溢出。


import java.util.Random;

//首先设置VM options为:-Xms10m -Xmx10m -XX:MaxDirectMemorySize=5m -XX:+PrintGCDetails
public class Test {
    public static void main(String[] args) {
        String str = "adf";
        while (true) {
            str += str + new Random().nextInt(1111111) + new Random().nextInt(222222);
            str.intern();
        }
    }
}
/*====================output========================
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 */

注意： StackOverflowError和OutOfMemoryError都是Error，而不是Exception

Case3：OOM—GC overhead limit exceeded

GC回收时间过长时会抛出OutofMemroyError过长的定义是，超过98％的时间用来做GC并且回收了不到2%的内存，连续多次GC都只回收了不到2％的极端情况下才会抛出。假如不抛出 GC overhead limit错误会发生什么情况呢？那就是GC清理的这么点内存很快会再次填满，迫使GC再执行，这样就形成恶性循环。CPU使用率一点是100%，而GC却没有任何成果。

这个错误是指：GC的时候会有“Stop the World"，STW越小越好，正常情况是GC只会占到很少一部分时间。但是如果用超过98%的时间来做GC，而且收效甚微，就会被JVM叫停。下例中，执行了多次Full GC，但是内存回收很少，最后抛出了OOM:GC overhead limit exceeded错误。

import java.util.ArrayList;
import java.util.List;

//首先设置VM options为:-Xms10m -Xmx10m -XX:MaxDirectMemorySize=5m -XX:+PrintGCDetails
public class Test {
    public static void main(String[] args) {
        int i = 0;
        List<String> list = new ArrayList<>();
        try {
            while (true) {
                list.add(String.valueOf(++i).intern());
            }
        } catch (Exception e) {
            System.out.println("************i" + i);
            e.printStackTrace();
            throw e;
        }
    }
}

/*====================output========================
[Full GC (Ergonomics) [PSYoungGen: 2047K->0K(2560K)] [ParOldGen: 7122K->633K(7168K)] 9170K->633K(9728K), [Metaspace: 3322K->3322K(1056768K)], 0.0056478 secs] [Times: user=0.08 sys=0.00, real=0.01 secs] 
 Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
 */

Case4：OOM—GC Direct buffer memory

在写NIO程序的时候，会用到ByteBuffer来读取和存入数据。

ByteBuffer.allocate(capability）：第一种方式是分配JVM内属于管辖范围，由于需要拷贝所以速度相对较慢
ByteBuffer. allocteDirect(capability）：第二种方式是分配OS本地内存，不属于GC管范围，由于不需要内存拷贝，所以速度相对较快。

但如果不断分配本地内存，堆内存很少使用，那么JVM就不需要执行GC，DirectByteBuffer对象就不会被回收。这时候内存充足，但本地内存可能已经使用光了，再片尝试分配本地内存就会出现OutOfMemoryError（直接内存溢出），那程序就接崩溃了。

与Java堆的数据不一样，ByteBuffer使用native方法，直接在堆外分配内存。当堆外内存（也即本地物理内存）不够时，就会抛出这个异常


import java.nio.ByteBuffer;

//首先设置VM options为:-Xms10m -Xmx10m -XX:MaxDirectMemorySize=5m -XX:+PrintGCDetails
public class Test {
    public static void main(String[] args) {
        System.out.println("配置的maxDirectMemory: " + (sun.misc.VM.maxDirectMemory() / (double) 1024 / 1024) + "MB");
        try {
            Thread.sleep(300);
        } catch (Exception e) {
            e.printStackTrace();
        }
        //本地内存设为5M，new一个6M的对象，会发生OutOfMemoryError
        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(6 * 1024 * 1024);
    }
}
/*====================output========================
配置的maxDirectMemory: 5.0MB
[GC (System.gc()) [PSYoungGen: 1884K->488K(2560K)] 1884K->784K(9728K), 0.0010243 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 488K->0K(2560K)] [ParOldGen: 296K->684K(7168K)] 784K->684K(9728K), [Metaspace: 3298K->3298K(1056768K)], 0.0053231 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
 */

Case5：OOM—unable to create new native thread

这个比较异常比较重要，因为经常应用到高并发场景。

导致原因：

你的应用创建了太多线程了，一个应用进程创建多个线程，超过系统承载极限
你的服务器并不许你的应用程序创建这么多线程，Linux系统默认允许单个进程可以创建的线程数是1024个，你的应用创建超过这个数量，就会报java.Lang.OutofMemoryError: unable to create new native thread

解决方法：

想办法降低你应用程序创建线程的数量，分析应用是否真的需要创建这么多线程，如不是，改代码将线程数降到最低
对于有些应用，确实需要创建很多线程，远超过Linux系统的默1024个线程的限制，可纵通过修改让Linux服务器配置，扩展Linux默认限制

详见UnableCreateNewThreadDemo

Case6：OOM—Metaspace

元空间满了就会抛出这个异常。方法区是一种规范，概念；元空间是方法区的实现。

Metaspace是方法区在 Hotspot中的实现，它与持久代最大的区别在于: Metaspace并不在虚拟机内存中而是使用本地内存。也即在java8中， classe metadata（ the virtual machines internal presentation of java class），被存储在叫做Metaspace的native memory，

Metaspace存放了以下信息：

虚拟机加载的类信息(类模板)

常量池

静态变量

即时编译后的代码

模拟Metaspace空间溢出，我们不断生成类(比如静态类)往元空间灌，类占据的空间总是会超过 Metaspace指定的空间大小的

JVM垃圾收集器

GC算法（引用计数/复制/标清/标记整理）是内存回收的方法论，垃圾收集器就是算法落地实现。因为目前为止还没有完美的收集器出现，更加没有万能的收集器，只是针对具体应用最合适的收集器，进行分代收集。

四大垃圾收集算法

1. 标记整理

2. 标记清除

3. 复制算法

4、分代收集算法

准确来讲，跟前面三种算法（省略引用计数算法）有所区别。分代收集算法就是根据对象的年代，采用上述三种算法来收集。

对于新生代：每次GC都有大量对象死去，存活的很少，常采用复制算法，只需要拷贝很少的对象。
对于老年代：常采用标整或者标清算法。

四类垃圾收集器

Java 8可以将垃圾收集器分为四类。

四种垃圾回收器

串行垃圾收集器Serial

为单线程环境设计且只使用一个线程进行GC，会暂停所有用户线程，不适用于服务器。就像去餐厅吃饭，只有一个清洁工在打扫。

并行垃圾收集器Parrallel

使用多个线程并行地进行GC，会暂停所有用户线程，适用于科学计算、大数据后台，交互性不敏感的场合。多个清洁工同时在打扫。停顿的时间会比串行垃圾收集器短。

并发垃圾收集器CMS

用户线程和GC线程同时执行（不一定是并行，交替执行），GC时不需要停顿用户线程，互联网公司多用，适用对响应时间有要求的场合。清洁工打扫的时候，也可以就餐。

上面三个垃圾回收的小总结：

G1垃圾收集器

对内存的划分与前面3种很大不同，G1将堆内存分割成不同的区域，然后并发地进行垃圾回收。

默认垃圾收集器

默认收集器有哪些？

有Serial、Parallel、ConcMarkSweep（CMS）、ParNew、ParallelOld、G1。还有一个SerialOld，快被淘汰了。

查看默认垃圾修改器

使用java -XX:+PrintCommandLineFlags即可看到，Java 8默认使用-XX:+UseParallelGC。

-XX:InitialHeapSize=132375936 -XX:MaxHeapSize=2118014976 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC

七大垃圾收集器(上面四种的实现，重要！)

体系结构

七种回收器的使用：
Serial(串行)
Parallel Scavenge(并行)
ParNew(只在新生代使用并行)；

SerialOld(原本用在养老区，已经不用啦)
ParallelOld(老年代的并行)
CMS(并发标记清除，用于回收老年代)

G1收集器，既可以回收新生代，也可以回收老年代。

连线表示可以搭配使用，红叉表示不推荐一同使用，比如新生代用Serial，老年代用CMS。并且，配置好新生代后，会默认配置好老年代相搭配的回收器。

配置好新生代后，会默认配置好老年代相搭配的回收器

部分参数说明

1. Serial收集器（Serial/Serial Copying）

一句话：一个单线程的收集器，在进行垃圾收集时候，必须暂停其他所有的工作线程直到它收集结束。

串行收集器是最古老，最稳定以及效率高的收集器，只使用一个线程去回收但其在进行垃圾收集过程中可能会产生较长的停顿（Stop- The-World”状态）。虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个CPU环境来说，没有线程交互的开销可以获得最高的单线程垃圾收集效率，因此 Serial垃圾收集器依然是java虛拟机运行在 Client模式下默认的新生代垃圾收集器。

其使用复制算法：

优点：单个线程收集，没有线程切换开销，拥有最高的单线程GC效率

缺点：收集的时候会暂停用户线程。

使用-XX:+UseSerialGC可以显式开启，开启后默认使用Serial+SerialOld的组合。

2. ParNew收集器

ParNew收集器其实就是 Seria收集器新生代的并行多线程版本，最常见的应用场景是配合老年代的 CMS GC工作，其余的行为和Seria收集器完全一样， ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。它是很多java虚拟机运行在 Server的默认新生代收集器，采用复制算法。

使用-XX:+UseParNewGC可以显式开启，开启后默认使用ParNew+SerialOld的组合。但是由于SerialOld已经过时，所以建议配合CMS使用。ParNew收集器只影响新生代，不影响老年代。

3. Parallel Scavenge收集器(JDK 1.8后默认)

ParNew收集器仅在新生代使用多线程收集，老年代默认是SerialOld，所以是单线程收集。而Parallel Scavenge在新、老两代都采用多线程收集。Parallel Scavenge还有一个特点就是吞吐量优先收集器，可以通过自适应调节，保证最大吞吐量。采用复制算法。

它重点关注的是:可控制的吞吐量（ Thoughput = 运行用户代码时间/ (运行用户代码时间+垃圾收集时间），也即比如程序运行100分钟，垃圾收集时间1分钟，吞吐量就是99％）。高吞吐量意味着高效利用CPU的时间，它多用于在后台运算而不需要太多交互的任务。

自适应调节策略也是parallelScavenge收集器与 ParDew收集器的一个重要区别。（自适应调节策略:虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间: MaxGCPause Millis）或最大的吞吐量。

常用JVM参数: XX: +Use ParalleIGC或-XX:+ Use ParalleloldGC（可互相激活）使用 Paralle！ Scavenge收集器开启该参数后:新生代使用复制算法，老年代使用标记-整理算法。

使用-XX:+UseParallelGC可以开启，同时也会使用ParallelOld收集老年代。其它参数，比如-XX:ParallelGCThreads=N可以选择N个线程进行GC，-XX:+UseAdaptiveSizePolicy使用自适应调节策略。

4. SerialOld收集器

Serial Old是 Seria垃圾收集器老年代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在 Client默认
的java虚拟机默认的年老代垃圾收集器。

在 Server模式下，主要有两个用途（了解，版本已经到8及以后）

在JDK1.5之前版本中与新生代的 Parallel Scavenge收集器搭配使用。（ Parallel Scavenge+ Serial old）
作为老年代版中使用CMS收集器的后备垃圾收集方案

5. ParallelOld收集器

Parallel Old收集器是 Parallel Scavenge的老年代版本，使用多线程的标记-整理算法，parallel Old收集器在JDK1.6才开始提供。

在JDK1.6之前，新生代使用 ParalleIScavenge收集器只能搭配年老代的 Serial old 收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量。在JDK1.6之前（ Parallel Scavenge+ Serial old），Parallel old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，JDK1.8后可以优先考虑新生代Parallel Scavenge和年老代 Parallel old收集器的搭配策略。在JDK1.8及后（ Parallel Scavenge+ Parallel old）

使用-XX:+UseParallelOldGC可以开启，同时也会使用Parallel收集新生代(JDK 1.8之后默认的就是这种组合)。

6. CMS收集器

CMS并发标记清除收集器，是标记清除(Mark-Sweep)算法的实现，是一种以获得最短GC停顿为目标的收集器。适用在互联网或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望停顿时间最短。是G1收集器出来之前大型应用的首选收集器。

在GC的时候，会与用户线程并发执行，不会停顿用户线程。但是在标记的时候，仍然会STW，只不过时间非常短。

使用-XX:+UseConcMarkSweepGC开启。开启过后，新生代默认使用ParNew，如果CMS收集效果不太理想，老年代会使用SerialOld作为CMS的后备收集器。

CMS有四步过程：

初始标记：只是标记一下GC Roots能直接关联的对象，速度很快，需要STW(暂停所有的工作线程)。

并发标记：主要标记过程，标记全部对象，和用户线程一起工作，不需要STW。

重新标记：修正在并发标记阶段出现的变动，需要STW。

并发清除：和用户线程一起，清除垃圾，不需要STW。

优缺点

优点：停顿时间少，响应速度快，用户体验好 (并发收集低停顿)。

缺点：

由于并发进行，CMS在收集与应用线程会同时会增加对堆内存的占用，也就是说，CMS必须要在老年代堆内存用尽之前完成垃圾回收，否则CMS回收失败时，将触发担保机制，串行老年代收集器将会以STW的方式进行一次GC，从而造成较大停顿时间

对CPU资源非常敏感：由于需要并发工作，多少会占用系统线程资源。

无法处理浮动垃圾：由于标记垃圾的时候，用户进程仍然在运行，无法有效处理新产生的垃圾。

产生内存碎片：由于使用标记清除算法，会产生内存碎片。

回收器的选择：

7. G1收集器

G1（ Garbage-First）收集器，是一款面向服务器端应用的收集器。

G1收集器与之前垃圾收集器的一个显著区别就是——之前收集器都有三个区域，新、老两代和元空间。而G1收集器只有G1区(garbage-first heap)和元空间(Metaspace)。而G1区，不像之前的收集器，分为新、老两代，而是一个一个Region，每个Region既可能包含新生代，也可能包含老年代。

G1收集器既可以提高吞吐量，又可以减少GC时间。最重要的是STW可控，增加了预测机制，让用户指定停顿时间。

CMS垃圾收集器虽然减少了暂停应用程序的运行时间，但是它还是存在着内存碎片问题。于是，为了去除内存碎片问题，同时又保留CMS垃圾收集器低暂停时间的优点，JAVA7发布了一个新的垃圾收集器——G1垃圾收集器。

主要改变是Eden， Survⅳor和 Tenured等内存区域不再是连续的了，而是变成了一个个大小一样的 region，每个 region从1M到32M不等。一个 region有可能属于Eden， Survivor或者 Tenured内存区域。

G1收集器的设计目标是取代CMS收集器，它同CMS相比，在以下方面表现的更出色，G1与CMS的区别：

G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片。

G1的 Stop The World（STW）更可控，G1在停顿时间上添加预测机制，用户可以指定期望停顿时间

G1整理空闲空间更快

G1需要更多的时间来预测GC停顿的时间

G1不希望牺牲大量的吞吐性能

G1不需要更大的Java Heap

使用-XX:+UseG1GC开启，还有-XX:G1HeapRegionSize=n、-XX:MaxGCPauseMillis=n等参数可调。

特点对比：

G1之前收集器的特点：

G1收集器的特点：

并行和并发：像CMS一样，能与应用程序线程并发执行。充分利用多核、多线程CPU，尽量缩短STW

分代收集：虽然还保留着新、老两代的概念（逻辑上分代），但物理上不再隔离，而是融合在Region中，Region也不要求连续，且会采用不同的GC方式处理不同的区域

空间整合：G1整体上看是标整算法，在局部看又是复制算法，不会产生内存碎片

可预测停顿：用户可以指定一个GC停顿时间，G1收集器会尽量满足

G1过程

与CMS类似，最大的好处是化整为零，只需要按照区域来进行扫描即可。

在堆的使用上，G1并不要求对象的存储一定是物理上连续的只要逻辑上连续即可，每个分区也不会固定地为某个代服务，可以按需在年轻代和老年代之间切换。启动时可以通过参数-XX:G1HeapRegionSize=n可指定分区大小（1MB~32MB，且必须是2的幂），默认将整堆划分为2048个分区。

大小范围在1MB~32MB，最多能设置2048个区域，也即能够支持的最大内存为:32MB*2048=65536MB=64G内存。

G1 YGC过程：

G1收集过程小结：

初始标记。

并发标记。

最终标记。

筛选回收。

G1收集过程

参考：https://github.com/MaJesTySA/JVM-JUC-Core/blob/master/docs/JVM.md