JVM学习笔记——垃圾回收篇

在本系列内容中我们会对JVM做一个系统的学习，本片将会介绍JVM的垃圾回收部分

我们会分为以下几部分进行介绍：

判断垃圾回收对象
垃圾回收算法
分代垃圾回收
垃圾回收器
垃圾回收调优

判断垃圾回收对象

本小节将会介绍如何判断垃圾回收对象

引用计数法

首先我们先来介绍引用计数法的定义：

我们为对象附上一个当前使用量
当有线程使用时，我们将该值加一；当线程停止使用时，我们将该值减一
当当前使用量大于零时，我们创建该对象；当当前使用量减少为零时，我们将该对象当作垃圾回收对象

但该方法存在一个致命问题：

当两个对象互相调用对方时，就会导致当前使用量一直不为空，占用内存

可达性分析算法

同样我们先来简单介绍可达性分析算法：

我们首先判定一些对象为Root对象
我们根据这些对象来选择判定其他对象是否为垃圾回收对象
当该对象直接或间接被Root对象所引用时，我们不设置为垃圾回收对象；当没有被Root对象连接时，设置为垃圾回收对象

然后我们来简单介绍一下Root对象的分类（来自MAT工具统计）：

System Class：直属于Java包下的相关类，包括有Object，String，Stream，Buffer等
Native Stack：直属于操作系统交互的类，包括有wait等
Busy Monitor：读锁机制相关的类，当前状态下被锁定的对象是无法当作垃圾回收对象的
Thread：互动线程，线程相关的类也无法当作垃圾回收对象

可达性分析算法就是目前Java虚拟机所使用的垃圾回收器判定方法

五种引用

下面我们将会介绍JVM中常用的五种引用方法，他们分别对应着不同的回收对象判定情况：

我们下面来一一介绍

强引用

上述图片中的A1对象就是强引用示例

我们下面介绍强引用的概念：

强引用就是由Root对象直接引用的对象

然后我们介绍强引用的回收概念：

只有当所有强引用连接都消失时，该对象才会被列为垃圾回收对象
例如上图，A1对象由B，C两个对象所强引用连接，只有当两个对象都取消引用后，A1对象才会被列入回收对象

软引用

上述图片中的A2对象就是软引用示例

我们下面介绍软引用的概念：

软引用不是由根Root直接引用，而是采用一个软引用对象SoftReference连接

然后我们介绍软引用的回收概念：

当该对象没有被强引用连接，被软引用连接时有可能会被回收
每次发生垃圾回收，如果垃圾回收后的内存够用，则不进行软引用对象的垃圾回收；若内存不足，则进行软引用对象的垃圾回收

此外我们的软引用对象也是会占用内存的，所以我们也需要采用其他方法将软引用对象回收：

我们通常将软引用对象绑定一个引用队列
当该软引用对象不再连接任何对象时，将其放入引用队列，引用队列会进行检测，检测到软引用对象就会对其进行垃圾回收

我们首先给出软引用对象的相关测试代码：

package cn.itcast.jvm.t2;

import java.io.IOException;

import java.lang.ref.SoftReference;

import java.util.ArrayList;

import java.util.List;

/**

 * 演示软引用

 * -Xmx20m -XX:+PrintGCDetails -verbose:gc

 */

public class Demo2_3 {

    private static final int _4MB = 4 * 1024 * 1024;

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

        // 这部分是强引用对象，我们会发现所有内存都放在内部，导致内存不足

        List<byte[]> list = new ArrayList<>();

        for (int i = 0; i < 5; i++) {

            list.add(new byte[_4MB]);

        }

        System.in.read();

        // 调用下列方法（软引用）

        soft();

    }

    // 软引用

    public static void soft() {

        // 软引用逻辑：list --> SoftReference --> byte[]

        // 创建软引用

        List<SoftReference<byte[]>> list = new ArrayList<>();

        for (int i = 0; i < 5; i++) {

            // 首先new一个SoftReference并赋值

            SoftReference<byte[]> ref = new SoftReference<>(new byte[_4MB]);

            System.out.println(ref.get());

            // 将SoftReference加入list

            list.add(ref);

            System.out.println(list.size());

        }

        System.out.println("循环结束：" + list.size());

        for (SoftReference<byte[]> ref : list) {

            System.out.println(ref.get());

        }

    }

}

/*

调试过程：

如果我们采用强引用方法，正常情况下会在第五次循环时报错

但是如果我们采用软引用，我们会在第五次循环时发生gc清理，这时我们前四次的添加（list的前四位）就会被软引用清除

所以我们在最后循环结束后查看数组会发现：

null

null

null

null

[B@330bedb4

*/

我们再给出软引用对象回收的相关测试代码：

package cn.itcast.jvm.t2;

import java.lang.ref.Reference;

import java.lang.ref.ReferenceQueue;

import java.lang.ref.SoftReference;

import java.util.ArrayList;

import java.util.List;

/**

 * 演示软引用, 配合引用队列

 */

public class Demo2_4 {

    private static final int _4MB = 4 * 1024 * 1024;

    public static void main(String[] args) {

        // 这里设置了List，里面的SoftReference是软引用对象，再在里面添加的数据就是软引用对象所引用的A2对象

        List<SoftReference<byte[]>> list = new ArrayList<>();

        // 引用队列（类型和引用对象的类型相同即可）

        ReferenceQueue<byte[]> queue = new ReferenceQueue<>();

        for (int i = 0; i < 5; i++) {

            // 关联了引用队列， 当软引用所关联的 byte[]被回收时，软引用自己会加入到 queue 中去

            SoftReference<byte[]> ref = new SoftReference<>(new byte[_4MB], queue);

            System.out.println(ref.get());

            list.add(ref);

            System.out.println(list.size());

        }

        // 从队列中获取无用的 软引用对象，并移除

        Reference<? extends byte[]> poll = queue.poll();

        while( poll != null) {

            list.remove(poll);

            poll = queue.poll();

        }

        System.out.println("===========================");

        for (SoftReference<byte[]> reference : list) {

            System.out.println(reference.get());

        }

    }

}

/*

和之前那此调试相同，前四次正常运行，在第五次时进行了gc清理

但是在循环结束之后，我们将软引用对象放入到了引用队列中并进行了清理，所以这时我们的list中前四次软引用对象直接消失

我们只能看到list中只有一个对象：

[B@330bedb4

*/

弱引用

上述图片中的A3对象就是弱引用示例

我们下面介绍强弱引用的概念：

弱引用不是由根Root直接引用，而是采用一个弱引用对象WeakReference连接

然后我们介绍弱引用的回收概念：

当该对象没有被强引用连接，被弱引用连接时在进行Full gc时会被强制回收
每次进行老年代的Full gc（后面会讲到Full gc，这里就当作大型垃圾回收）时都会被强制回收

此外我们的弱引用对象也是会占用内存的，所以我们也需要采用相同方法将弱引用对象回收：

我们通常将弱引用对象绑定一个引用队列
当该弱引用对象不再连接任何对象时，将其放入引用队列，引用队列会进行检测，检测到弱引用对象就会对其进行垃圾回收

我们同样给出弱引用对象的垃圾回收示例代码：

package cn.itcast.jvm.t2;

import java.lang.ref.Reference;

import java.lang.ref.ReferenceQueue;

import java.lang.ref.SoftReference;

import java.lang.ref.WeakReference;

import java.util.ArrayList;

import java.util.List;

/**

 * 演示弱引用

 * -Xmx20m -XX:+PrintGCDetails -verbose:gc

 */

public class Demo2_5 {

    private static final int _4MB = 4 * 1024 * 1024;

    public static void main(String[] args) {

        //  list --> WeakReference --> byte[]

        List<WeakReference<byte[]>> list = new ArrayList<>();

        for (int i = 0; i < 10; i++) {

            WeakReference<byte[]> ref = new WeakReference<>(new byte[_4MB]);

            list.add(ref);

            for (WeakReference<byte[]> w : list) {

                System.out.print(w.get()+" ");

            }

            System.out.println();

        }

        System.out.println("循环结束：" + list.size());

    }

}

/*

这时我们的小型gc（新生代gc）是不会触发弱引用全部删除的（新生代我们后面会讲到）

只有当内存全部占满后，触发的Full gc才会导致弱引用的必定回收

例如我们在第5，7次新生代发生内存占满，这时触发了新生代的gc，但是只会删除部分WeakReference

当我们第9次新生代，老生代内存全部占满后会发生一次Full gc，这时就会引起全部弱引用数据删除，所以我们的数据会变成：

null

null

null

null

null

null

null

null

null

[B@330bedb4

*/

虚引用

上述图片中的ByteBuffer对象就是虚引用示例

我们下面介绍虚引用的概念：

虚引用实际上就是直接内存的引用，我们内存结构篇所学习的ByteBuffer就是例子
系统首先会创建一个虚引用，然后这个虚引用会创建一个ByteBuffer对象，ByteBuffer对象通过unsafe来管理直接内存
此外，我们的虚引用必定需要绑定一个引用队列，因为我们的byteBuffer对象是无法控制直接内存的，我们需要检测虚引用来删除

然后我们介绍虚引用的回收概念：

首先我们会手动删除或者系统垃圾回收掉ByteBuffer对象
这时我们的虚引用和直接内存是不会消失的，但是我们的虚引用会被带到引用队列中
虚引用中携带者Cleaner对象，引用队列会一直检测是否有Cleaner对象进入，当检测到时会执行这个Cleaner方法来删除直接内存

我们需要注意的是：

引用队列中检测Cleaner对象的优先级较高，所以效率相关而言比较快

终结器引用

上述图片的A4对象就是终结器引用

我们下面介绍终结器引用的概念：

终结器引用实际上是对象自己定义的finallize方法
终结器对象同样也需要绑定引用队列，因为他需要靠终结器对象来清除内部对象

然后我们介绍终结器引用的回收概念：

如果我们希望清除终结器引用的对象，那么我们需要先将终结器引用对象导入到引用队列中
引用队列中同样也会一直检测是否出现终结器对象，若出现终结器对象，那么针对该终结器对象调用其内部对象的finallize方法删除

我们需要注意的是：

引用队列中检测终结器对象的优先级较低，所以效率相关而言比较慢

垃圾回收算法

本小节将会介绍垃圾回收的三种基本回收算法

标记清除法

我们首先给出简单图示：

我们来做简单解释：

首先我们找出需要进行垃圾回收的部分并进行标记
然后我们将该标记地址部分清除即可（注意：这里的清除仅仅是记录起始地址和终止地址，然后在其他内存占用时再次覆盖）

该算法的优缺点：

执行速度极快
但会产生内存碎片，当内存碎片逐渐增多会导致问题

标记整理法

我们首先给出简单图示：

我们来做简单解释：

首先我们根据Root标记出需要垃圾回收的部分
然后我们将垃圾回收的部分抛出之后，将后面的部分进行地址腾挪，使其紧凑

该算法的优缺点：

不会产生内存碎片，导致内存问题
速度较慢，同时整理过程中其他进程全部停止（因为会涉及内存地址重塑，进行其他进程可能会导致内存放置地址错误）

区域复制法

我们首先给出简单图示：

我们来做简单解释：

我们准备两块完全相同的区间，将他们分为From和To区间
我们首先在from区间存储数据，我们直接进行垃圾回收判定
然后将需要保存的数据直接放入To区间，垃圾回收的部分不需要管理
最后我们将From和To区间的定义交换，将新添加的数据放入现在的From区间（之前腾挪的To区间）

该算法的优缺点：

不会产生内存碎片，相对而言比较迅速
但需要占用两块相同的地址空间，导致占用空间较多

分代垃圾回收机制

本小节将会介绍垃圾回收的常用机制

分代垃圾回收机制介绍

我们前面已经介绍了三种垃圾回收算法，但实际上我们的垃圾回收采用的是三种方法的组合方法：

我们首先对大概念进行介绍：

新生代：用于存放新产生的内存数据，清除频繁
老生代：用于存放一直使用的内存数据，只有当内存占满时才会清理

然后我们对小概念进行介绍：

伊甸园：用于存放所有的新产生的内存数据
幸存区From：用于存放未被垃圾回收的数据
幸存区To：用于进行未被垃圾回收的数据的复制方法
幸存值：用于表示内存数据的常用程度，所有内存数据进入时默认值为0，

然后我们对整个回收机制进行介绍：

首先我们的新数据都会进入到新生代的伊甸园中去，默认幸存值为0
当伊甸园数据满后，会进行gc，这时我们进行标记清除法，将不需要的内存筛出
同时将幸存下来的内存数据放入到幸存区From，幸存值+1，同时进行From和To区间的对调
我们继续进行储存直到伊甸园再次占满，对整个新生代进行gc
首先将幸存区From的幸存内存放入To中并将伊甸园的幸存数据放入To，进行区间调换，幸存值+1
直到幸存值达到一个阈值（默认为6或者15），该内存数据就会被移动到老年代，新生代仍旧继续工作
直至新生代和老年代全部都占满后，这时我们就需要进行大型的垃圾回收，也就是我们之前提到的Full gc！

分代垃圾回收相关VM参数

我们下面介绍一下分代垃圾回收机制的相关参数：

含义	参数
堆初始大小	-Xms
堆最大大小	-Xmx 或 -XX:MaxHeapSize=size
新生代大小	-Xmn 或 (-XX:NewSize=size + -XX:MaxNewSize=size )
幸存区比例（动态）	-XX:InitialSurvivorRatio=ratio 和 -XX:+UseAdaptiveSizePolicy
幸存区比例	-XX:SurvivorRatio=ratio
晋升阈值	-XX:MaxTenuringThreshold=threshold
晋升详情	-XX:+PrintTenuringDistribution
GC详情	-XX:+PrintGCDetails -verbose:gc
FullGC 前 MinorGC (小gc)	-XX:+ScavengeBeforeFullGC

分代垃圾回收案例展示

我们通过一个简单的实例来展示分代垃圾回收的实际演示：

// 相关配置信息：配置默认大小，设置回收方法，显示GC详情，开启FullGC前进行gc

// -Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc -XX:-ScavengeBeforeFullGC

/*

首先我们展示不添加内存的状况

*/

package cn.itcast.jvm.t2;

import java.util.ArrayList;

public class Demo2_1 {

    private static final int _512KB = 512 * 1024;

    private static final int _1MB = 1024 * 1024;

    private static final int _6MB = 6 * 1024 * 1024;

    private static final int _7MB = 7 * 1024 * 1024;

    private static final int _8MB = 8 * 1024 * 1024;

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

        new Thread(() -> {

            ArrayList<byte[]> list = new ArrayList<>();

        }).start();

        System.out.println("sleep....");

        Thread.sleep(1000L);

    }

}

/*

其中def new generation，eden space是新生代，tenured generation是老年代，from，to幸存区

Heap

 def new generation   total 9216K, used 4510K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)

  eden space 8192K,  55% used [0x00000000fec00000, 0x00000000ff067aa0, 0x00000000ff400000)

  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)

  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)

 tenured generation   total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)

   the space 10240K,   0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)

 Metaspace       used 4362K, capacity 4714K, committed 4992K, reserved 1056768K

  class space    used 480K, capacity 533K, committed 640K, reserved 1048576K

*/

/*

然后我们展示添加1mb的情况

*/

package cn.itcast.jvm.t2;

import java.util.ArrayList;

public class Demo2_1 {

    private static final int _512KB = 512 * 1024;

    private static final int _1MB = 1024 * 1024;

    private static final int _6MB = 6 * 1024 * 1024;

    private static final int _7MB = 7 * 1024 * 1024;

    private static final int _8MB = 8 * 1024 * 1024;

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

        new Thread(() -> {

            ArrayList<byte[]> list = new ArrayList<>();

            list.add(new byte[_1MB]);

        }).start();

        System.out.println("sleep....");

        Thread.sleep(1000L);

    }

}

/*

我们可以发现新生代数据增加，老年代未发生变化

Heap

 def new generation   total 9216K, used 5534K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)

  eden space 8192K,  67% used [0x00000000fec00000, 0x00000000ff167a40, 0x00000000ff400000)

  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)

  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)

 tenured generation   total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)

   the space 10240K,   0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)

 Metaspace       used 4354K, capacity 4714K, committed 4992K, reserved 1056768K

  class space    used 480K, capacity 533K, committed 640K, reserved 1048576

*/

/*

最后需要补充讲解一点：当我们的新生代不足以装载数据内存时，我们会直接将其装入老年代（老年代能够装载情况下）

*/

package cn.itcast.jvm.t2;

import java.util.ArrayList;

public class Demo2_1 {

    private static final int _512KB = 512 * 1024;

    private static final int _1MB = 1024 * 1024;

    private static final int _6MB = 6 * 1024 * 1024;

    private static final int _7MB = 7 * 1024 * 1024;

    private static final int _8MB = 8 * 1024 * 1024;

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

        new Thread(() -> {

            ArrayList<byte[]> list = new ArrayList<>();

            list.add(new byte[_8MB]);

        }).start();

        System.out.println("sleep....");

        Thread.sleep(1000L);

    }

}

/*

我们会发现eden的值未发生变化，但是tenured generation里面装载了8192K

Heap

 def new generation   total 9216K, used 4510K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)

  eden space 8192K,  55% used [0x00000000fec00000, 0x00000000ff067a30, 0x00000000ff400000)

  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)

  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)

 tenured generation   total 10240K, used 8192K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)

   the space 10240K,  80% used [0x00000000ff600000, 0x00000000ffe00010, 0x00000000ffe00200, 0x0000000100000000)

 Metaspace       used 4360K, capacity 4714K, committed 4992K, reserved 1056768K

  class space    used 480K, capacity 533K, committed 640K, reserved 1048576K

*/

/*

当然，当我们的新生代和老年代都不足以装载时，系统报错~

*/

package cn.itcast.jvm.t2;

import java.util.ArrayList;

public class Demo2_1 {

    private static final int _512KB = 512 * 1024;

    private static final int _1MB = 1024 * 1024;

    private static final int _6MB = 6 * 1024 * 1024;

    private static final int _7MB = 7 * 1024 * 1024;

    private static final int _8MB = 8 * 1024 * 1024;

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

        new Thread(() -> {

            ArrayList<byte[]> list = new ArrayList<>();

            list.add(new byte[_8MB]);

            list.add(new byte[_8MB]);

        }).start();

        System.out.println("sleep....");

        Thread.sleep(1000L);

    }

}

/*

我们首先会看到他在Full gc之前做了一次小gc，然后做了一次Full gc，可是这并无法解决问题

[GC (Allocation Failure) [DefNew: 4345K->999K(9216K), 0.0016573 secs][Tenured: 8192K->9189K(10240K), 0.0022899 secs] 12537K->9189K(19456K), [Metaspace: 4352K->4352K(1056768K)], 0.0039931 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

[Full GC (Allocation Failure) [Tenured: 9189K->9124K(10240K), 0.0018331 secs] 9189K->9124K(19456K), [Metaspace: 4352K->4352K(1056768K)], 0.0018528 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

然后系统进行报错

Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space

	at cn.itcast.jvm.t2.Demo2_1.lambda$main$0(Demo2_1.java:20)

	at cn.itcast.jvm.t2.Demo2_1$$Lambda$1/1023892928.run(Unknown Source)

	at java.lang.Thread.run(Thread.java:750)

最后我们可以看到老年代占用了89%，第一个数据仍旧保存，但第二个数据无法保存导致报错

Heap

 def new generation   total 9216K, used 366K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)

  eden space 8192K,   4% used [0x00000000fec00000, 0x00000000fec5baa8, 0x00000000ff400000)

  from space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)

  to   space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)

 tenured generation   total 10240K, used 9124K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)

   the space 10240K,  89% used [0x00000000ff600000, 0x00000000ffee93c0, 0x00000000ffee9400, 0x0000000100000000)

 Metaspace       used 4379K, capacity 4704K, committed 4992K, reserved 1056768K

  class space    used 480K, capacity 528K, committed 640K, reserved 1048576K

我们还需要注意的是：即使内存不足发生报错，但该程序不会结束；系统只会释放自己当前项目的进程而不会影响其他进程

*/

垃圾回收器

前面我们已经介绍了垃圾回收机制，现在我们来介绍常用的垃圾回收器

STW概念

我们在正式讲解垃圾回收器之前，我们先来回顾一个概念STW：

STW即Stop The World，意思是暂停所有进程处理
因为我们在进行垃圾处理时，会涉及到地址空间的整合（标记整理法），这时所有CPU都需要停止操作

串行垃圾回收器

我们首先来介绍串行垃圾回收器的特点：

单线程
适用于堆内存较小，适合单人电脑

我们给出串行垃圾回收器的展示图：

我们所需配置：

// 设置 新生代回收方法复制 老年代回收方法为标记整理法

-XX:+UseSerialGC = Serial + SerialOld

我们来简单解释一下：

串行操作属于单核CPU处理
我们在处理该CPU的垃圾回收时，只有该线程的CPU进行操作
但同时老年代采用标记整理法会涉及到内存地址重新规划，所以其他CPU也需要暂停操作，即STW

吞吐量优先垃圾回收器

我们首先来介绍吞吐量优先垃圾回收器的特点：

多线程
适用于堆内存较大，需要多核CPU
让单位时间内，STW时间最短，例如每次STW0.2秒，但执行两次，共用0.4s（总时间最短）

我们给出吞吐量优先垃圾回收器的展示图：

我们所需配置：

// 设置垃圾回收器方法

XX:+UseParallelGC ~ -XX:+UseParallelOldGC

// 自适应新生代晋升老年代的阈值处理

-XX:+UseAdaptiveSizePolicy

// 设置垃圾回收时间占总时间的比例（与-XX:MaxGCPauseMillis=ms冲突）

-XX:GCTimeRatio=ratio

// 设置最大STW时间（与-XX:GCTimeRatio=ratio冲突）

-XX:MaxGCPauseMillis=ms

// 设置最大同时进行CPU个数

-XX:ParallelGCThreads=n

我们来简单解释一下：

吞吐量优先垃圾回收器是多核CPU处理回收器
当一个进程发生垃圾回收时，我们会将所有CPU都用于垃圾回收，这时CPU利用率为100%

响应时间优先垃圾回收器

我们首先来介绍响应时间优先垃圾回收器的特点：

多线程
适用于堆内存较大，需要多核CPU
让单次STW时间最短，例如每次STW0.1秒，但执行五次，共用0.5s（单次时间最短）

我们给出响应时间优先垃圾回收器的展示图：

我们所需配置：

// +UseConcMarkSweepGC：设置并发标记清除算法，允许用户进程单独进行，但部分时间还需要阻塞

// -XX:+UseParNewGC：设置新生代算法，

// SerialOld：当老年代并发失败，采用单线程方法

-XX:+UseConcMarkSweepGC ~ -XX:+UseParNewGC ~ SerialOld

// -XX:ParallelGCThreads=n：并行数设置为n

// -XX:ConcGCThreads=threads：并发线程最好设置为CPU的1/4个数，相当于只有1/4个CPU在处理垃圾回收

-XX:ParallelGCThreads=n ~ -XX:ConcGCThreads=threads

// 预留空间（因为并发清理时其他进程可能会产生一些垃圾，这些垃圾目前无法处理，我们需要预留一定空间进行储存）

-XX:CMSInitiatingOccupancyFraction=percent

// 我们在重新标记阶段前，先对新生代进行垃圾回收，节省其标记量

-XX:+CMSScavengeBeforeRemark

我们来简单解释一下：

响应时间优先垃圾回收器是多核CPU处理回收器
首先我们的CPU1进行初始标记，其他进程阻塞，仅标记一些Root对象（时间短）
然后我们CPU1进行并发标记，其他进程继续运行，这时用来标记所有的垃圾回收对象（时间长）
然后由于我们的并发标记可能会导致一些内存混乱，所以我们将所有CPU需要进行重新标记（时间短）
最后只需要对CPU1进行并发清理即可，其他进程继续运行

G1垃圾回收器

下面我们将会针对jdk1.9默认垃圾回收器做一个详细的介绍

G1垃圾回收器简介

首先我们先来简单介绍一下G1垃圾回收器：

G1回收器：Garbage First
在2017成为JDK9的默认垃圾回收器

下面我们来介绍G1垃圾回收器的特点：

同时注重吞吐量和低延迟，默认的暂停目标是200ms
超大堆内存，将堆划分为多个大小相等的Region
整体上是标记整理法，但两个区域之间是复制算法

G1垃圾回收器阶段简介

我们通过一张图来简单介绍G1垃圾回收器的过程：

我们可以看到整个流程分为三个阶段：

YoungCollection：新生代阶段
YoungCollection+ConcurrentMark：新生代阶段+并发标记阶段
MixedCollection：混合收集阶段

Young Collection

我们首先给出该阶段的展示图：

我们对其进行解释：

E就是伊甸园，S就是幸存区，O就是老年代
其产生的正常流程就和分代垃圾回收机制一样，但这阶段不会产生GC

Young Collection + CM

我们首先给出该阶段的展示图：

我们对其进行解释：

其字符含义完全相同
当新生代内存占满后进行Young GC时会同时进行GC Root的初始标记
老年代占用堆空间比例达到阈值时，进行并发标记（不会产生STW），阈值可以控制

我们给出并发标记阈值控制语句：

// 阈值控制

-XX:InitiatingHeapOccupancyPercent=percent （默认45%）

Mixed Collection

我们首先给出该阶段的展示图：

我们对其进行解释：

其字符含义完全相同
但该阶段会对E，S，O进行全面垃圾回收
其中最终标记（Remark）和拷贝存活（Evacation）都会STW（我们均会在后面解释）

我们需要注意一点：

Mixed Collection可能并不会将所有老年代的数据都删除
它会根据你设置的最大暂停时间来进行抉择，如果时间不足以删除所有老年代数据，就会挑选部分较大的内存数据进行回收

Full GC

我们需要重新总结一下Full GC操作：

SerialGC（串行垃圾回收）

新生代内存不足时发生的垃圾收集 - minor gc
老年代内存不足时发生的垃圾收集 - full gc

ParalllelGC(吞吐量优先垃圾回收)

新生代内存不足时发生的垃圾收集 - minor gc
老年代内存不足时发生的垃圾收集 - full gc

CMS（响应时间优先垃圾回收）

新生代内存不足时发生的垃圾收集 - minor gc
老年代内存不足时优先进行标记操作同步垃圾回收，当内存完全占满后才采用full gc

G1（Garbage First）

新生代内存不足时发生的垃圾收集 - minor gc
老年代内存不足时优先进行MixedCollection同步垃圾回收，当内存完全占满后才采用full gc

G1知识点补充

我们在前面已经提到了我们将堆划分为多个Region

但其实这个Region并不仅仅只分为了E，S，O三个空间，此外还包括以下空间：

RSet（Remember Set ：记忆集合）

/*

每一个Region都会划出一部分内存用来储存记录其他Region对当前持有Rset Region中Card的引用

针对G1的垃圾回收时间设置较短，在进行标记过程中可能会导致时间过长，所以我们设置了RSet来储存部分信息

我们可以直接通过扫描每块Region里面的RSet来分析垃圾比例最高的Region区，放入CSet中，进行回收。

*/

CSet（Collection Set 回收集合）

/*

收集集合代表每次GC暂停时回收的一系列目标分区。

在任意一次收集暂停中，CSet所有分区都会被释放，内部存活的对象都会被转移到分配的空闲分区中。

年轻代收集CSet只容纳年轻代分区，而混合收集会通过启发式算法，在老年代候选回收分区中，筛选出回收收益最高的分区添加到CSet中。

*/

新生代跨代引用

由于我们的初次标记时会去寻找Root部分

但其实大部分的Root都放入了老年代，但老年底数据较多难以查找，所以G1提供了一种方法：

将老年代O再次划分为多个区间，名为卡
如果该卡中存储了Root部分，那么就将该卡标记为脏卡，同时放于RSet中存储起来便于查找

我们给出简单图示：

同时如果该Root地址发生变化，G1给出了另外的方法进行更换：

在引用变更时通过post-write barrier + dirty card queue
concurrent refinement threads 更新 Remembered Set

Remark重新标记

我们在进行标记时通常采用三色标记法：

我们做简单介绍：

黑色是已经标记结束的内存
灰色是正在标记的内存
白色是未标记的内存

我们针对上述进行分析：

最左侧是根，黑色，已经被标记
上方为根的直接/间接引用对象，黑色，已经被标记
下方为根的直接/间接引用对象，灰色，正在标记，白色，还未被标记当后面会被标记
最右侧孤零零的白色方块，没有被引用，不会被标记，最后会被当作垃圾回收对象处理掉

这时我们就会发现一个问题：

如果最右侧的方块在针对自身的CPU的并发标记结束后，又被其他进程所调用了（并发标记其他CPU正常运行）
但是此时它是白色的，最终会被这次的垃圾回收操作清除掉，就会导致影响其他进程操作

所以我们设计了Remark重新标记操作：

如果在该方块针对自身的并发标记结束后又被其他进程调用，这时将他拖入一个队列中，并将其变为灰色
在并发标记结束后进入重新标记阶段，就会检查该队列，若发现灰色对象，在队列中将它变为黑色对象并排出队列

G1垃圾回收器重要更新

下面我们将会针对G1垃圾回收器在各个版本的重要更新做个介绍

JDK 8u20 字符串去重

我们首先要明白字符串在底层是采用char数组形成的：

String s1 = new String("hello"); // char[]{'h','e','l','l','o'}

String s2 = new String("hello"); // char[]{'h','e','l','l','o'}

如果重复的字符串都存放在内存中肯定会导致内存多余占用，所以提供了解决方案：

将所有新分配的字符串放入一个队列
当新生代回收时，G1并发检查是否有字符串重复
如果它们值一样，让它们引用同一个 char[]
注意与 String.intern() 不一样：一个底层针对String类型，一个底层针对char[]类型

其优缺点：

优点：节省大量内存
缺点：略微增多了CPU时间，新生代回收时间略微增多

JDK 8u40 并发标记类卸载

当所有的类都经过并发标记后，就会直到哪些类不再被使用

这时如果一个类加载器的所有类都不再使用时，我们就可以卸载它所加载的所有类

JDK 8u60 回收巨型对象

首先我们介绍一下巨型对象的定义：

一个对象大于 region 的一半时，称之为巨型对象

然后我们再来介绍G1对巨型对象的处理方法：
回收时被优先考虑
G1 不会对巨型对象进行拷贝
G1 会跟踪老年代所有 incoming 引用，这样老年代 incoming 引用为0 的巨型对象就可以在新生代垃圾回收时处理掉

垃圾回收调优

本小节将会介绍垃圾回收的调优机制

基本调优概念

我们进行调优需要掌握的基本知识：

掌握相关工具使用
掌握基本的空间调整
掌握GC相关的VM参数
明白调优并非固定公式，而是需要结合应用，环境

我们调优的领域并非只有垃圾回收，但是这个部分的调优确实会给项目带来很大的速率优化，此外还有其他方法的调优：

IO调优
锁竞争调优
CPU占用调优

此外我们需要确定调优的目标：

是为了保证低延迟还是为了保证高吞吐量

最快的GC是不发生GC

首先我们需要明白GC是花费时间的，如果我们能够控制好内存保证不发生GC，那么才是最快的

如果我们频繁发生GC操作，那么我们就需要先进行自我反思：

存放的数据是否过多？

/*

例如我们是否设置了相同元素筛选？错误账号禁止缓存？

*/

数据表示是否臃肿？

/*

例如我们调取数据时是否只调取了我们所需数据还是全盘托出？

例如我们选择数据类型时是否是以最低标准为要求，数据库能采用tiny不要使用int

*/

是否存在内存泄露？

/*

例如我们是否设置缓存数据时采用了Static形式的Map并不断存储数据？

*/

新生代调优

首先我们先来回顾一下新生代的优点：

所有的new操作的内存分配十分廉价：直接new出来存放在伊甸区即可
死亡对象的回收代价为零：我们直接采用复制将幸存内存复制出来即可，其他垃圾回收部分不用过问
大部分对象都是垃圾：我们实际上幸存下来的内存数据是小部分数据，所以大部分都是垃圾
垃圾回收时间相对短：Minor GC的时间远低于Full GC

那么我们该怎么进行调优呢：

最简单的方法就是适当扩大新生代空间即可
新生代不易太小：如果新生代过小就会导致不断发生minor GC浪费时间，且幸存区过小导致无用数据都存入老年代
新生代不易太大：如果新生代过大相对老年代空间变小，容易发生Full GC，Full GC的运行时间过长

那么官方认可的新生代大小为多少：

新生代能容纳所有[并发量*（请求-响应）]的数据

新生代幸存区调优

首先我们需要直到新生代幸存区存放的数据主要分为两部分：

当前活跃对象：并不应该晋级到老年代，只是目前阶段需要使用的内存数据
需要晋升对象：我们一直使用的内存数据，需要传递到老年代

首先我们需要保证具有一定的幸存区大小：

如果幸存区过小，就会导致幸存区数据提前进入到老年代
但如果是当前活跃对象进入到老年代，既不能发挥作用，并且也难以排出老年代

其次我们需要控制晋升标准：

设置一定规格的晋升标准，防止部分当前活跃对象进入到老年代，理由同上

老年代调优

最后我们介绍一下老年代调优，我们这里以CMS为例：

首先CMS老年代内存越大越好
其次在不做调优的情况下，如果没有发生Full GC就不需要调优了，否则优先调优新生代
如果经常发生Full GC，我们就需要将老年代空间增大了，官方推荐增大目前老年代空间大小的1/4~1/3即可

调优案例展示

最后我们介绍三个调优方法的案例：

Full GC和Minor GC频繁

/*

主要是因为新生代空间不足

因为新生代空间不足，经常发生minor GC，同时幸存区空间不足导致大量数据直接进入到老年代，最后导致老年代也产生Full GC

*/

请求高峰期发生 Full GC，单次暂停时间特别长（CMS）

/*

首先我们已经直到是CMS的垃圾回收方法

我们在之前的学习中得知Full GC主要分为三个阶段：初始标记，并发标记，重新标记

在请求高峰期期间，数据较多，我们的重新标记由于需要重新扫描所有数据空间，所以会导致单次暂停时间长

我们只需要保证在进行重新扫描前先进行一次Minor GC消除掉无用数据就可以加快暂停速度：-XX:+CMSScavengeBeforeRemark

*/

老年代充裕情况下，发生 Full GC （CMS jdk1.7）

/*

首先我们需要注意是jdk1.7版本

在1.7版本是由永久代负责管理方法区以及常量池，如果永久代内存满了也会产生Full GC

所以我们只需要增加永久代的内存大小即可

*/

结束语

到这里我们JVM的垃圾回收篇就结束了，希望能为你带来帮助~

附录

该文章属于学习内容，具体参考B站黑马程序员满老师的JVM完整教程

这里附上视频链接：01_垃圾回收概述_哔哩哔哩_bilibili