JVM学习笔记——垃圾回收篇
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
- 整体上是标记整理法，但两个区域之间是复制算法
相关JVM参数：
- -XX:+UseG1GC 使用G1垃圾回收器（JDK9之前都不是默认回收器）
- -XX:G1HeapRegionSize=size 设置Region的大小
- -XX:MaxGCPauseMillis=time 设置最大的G1垃圾回收时间
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
