概述
垃圾回收关注点
运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾
为什么需要垃圾回收
对于高级语言，如果不及时进行垃圾回收，内存迟早会被消耗完，因为不断地分配内存空间而不进行回收，就好像不停的生产垃圾而从来不打扫
- 除了释放没用的对象，垃圾回收也可以清除内存里的记录碎片，碎片整理将所占用的堆内存移到堆的一段，以便JVM将整理的内存分配给新的对象
应用程序越来越复杂，用户越来越多，没有GC不能保证程序的正常进行。而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化
早期的垃圾回收
手工进行：new内存申请，delete内存释放
灵活，但是管理繁琐，经常会有忘记回收，导致内存泄漏，直至内存溢出
Java的内存管理
优点
自动内存管理，无需手动参与内存的分配与回收，降低内存泄漏和内存溢出的风险
缺点
内存管理就像是一个黑匣子，如果过度依赖自动，最严重的就是弱化Java开发人员在程序出现内存溢出时定位和解决问题的能力
回收区域
堆
-
各区域频率
频繁收集新生区
- 较少收集年老区
-
GC分类
Minor GC
新生区空间不足的时候触发，主要指Eden区，Survivor区满并不出发GC（只是被动的接收GC）
- GC频率高，回收速度快
会引发SWT，暂停其他用户的线程，等垃圾回收结束，用户线程才恢复运行
Major GC
年老区的GC，触发前会执行一次Minor GC，如果空间还不足才触发Major GC
- 比Minor GC慢10倍以上，STW的时间更长（调优关键）
-
Full GC
调用System.gc()，系统建议Full GC，但是不必然执行
- 年老区空间不足
- 方法区空间不足
- 通过Minor GC后进入年老区的平均大小大于年老区的可用内存
由Eden区、survivor space (From Space）区向survivor space1 (To Space)区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小说明: full gc是开发或调优中尽量要避免的。这样暂时时间会短一些。
垃圾回收算法
标记阶段
判断GC进行垃圾回收之前，区分出内存中哪些是存活对象，哪些是已经死亡的对象
- 只有被标记为已死亡的对象，在执行GC的时候才会进行垃圾回收，释放其所占用的内存空间
-
引用计数算法
Reference Counting，比较简单，每个对象保存到一个整形的引用计数器属性，用于记录对象被引用的情况
对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1，引用失效时减1，当A的引用计数器的值为0时，A就不再使用，可进行回收
优点
实现简单
- 垃圾对象便于识辨，判定效率高
-
缺点
需要单独的字段存储计数器，增加了空间开销
- 每次赋值都需要更新计数器，增加了时间开销
无法处理循环引用问题（为什么JVM不采用引用计数算法？）
什么是循环依赖
A引用了B，B引用了Apublic class Demo1 {private byte[] bytes = new byte[500 * 1024 * 1024];Demo1 reference = null;public static void main(String[] args) throws InterruptedException {Demo1 demo1 = new Demo1();Demo1 demo2 = new Demo1();demo1.reference = demo2;demo2.reference = demo1;}}
Python如何解决循环引用
-
优点
实现简单、执行高效
-
思路
可达性分析算法是以根对象集合(GC Roots，一组必须活跃的引用)为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达
- 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链(Reference Chain)
- 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象
- 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象
- 如果只针对堆中的某一块区域进行垃圾回收，则必须考虑到内存区域是虚拟机自己的实现细节，而不是孤立封闭式的，这个区域的对象可能会被其他区域的对象引用，这时候就需要一并将关联的区域对象也加入GC Roots集合中去考虑，才能保证可达性分析的准确性
- 分析工作必须在一个能保障一致性的快照中进行，不满足则分析结果的准确性无法保证（STW的原因！停止用户线程、对垃圾对象进行标记）
GC Roots
- 虚拟机栈用引用的对象，如各个线程被调用的方法中使用到的参数、局部变量等
- 本地方法栈JNT引用的对象
- 类静态属性引用的对象，如Java的引用类型静态变量
- 方法区中常量引用的对象，如字符串常量池里的引用
- 所有被同步锁synchronized持有的对象
- Java虚拟机内部的引用，如一些常驻的异常对象Null PointerException、OutOfMemory、系统类加载器等
- 反应java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等
由于Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root
对象的finalization机制
Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑
- 当垃圾回收器发现没有引用指向一个对象，即:垃圾回收此对象之前，先调用这个对象的finalize()方法。
- finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。
- 永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用。理由包括下面三点：
- 在finalize()时可能会导致对象复活
- finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行机会
- 一个糟糕的finalize()会严重影响GC的性能
- 从功能上来说，finalize()方法与C++中的析构函数比较相似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize()方法在本质上不同于c++中的析构函数。由于finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态。
- 如果从所有的根节点都无法访问到某个对象，说明对象己经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段。一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中的对象可能的三种状态。如下:
- 可触及的：从根节点开始，可以到达这个对象。
- 可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活。
- 不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一次
- 以上3种状态中，是由于finalize()方法的存在，进行的区分。只有在对象不可触及时才可以被回收。
具体过程
- 判定一个对象是否可以回收，至少需要两次标记过程：没有引用链，进行第一次标记
判断此对象是否有必要执行finalize()方法，调用过、方法没有重写的的没必要执行；如果有必要执行，则对象会被插入到F-Queue队列中，由一个虚拟机自动创建的、低优先级的Finalizer线程触发其finalize()方法执行；稍后GC会对F-Queue队列中的对象进行第二次标记，如果 finalize()方法中与引用链上的任何一个对象建立了联系，那么第二次标记时，这个对象就会被移出“即将回收”集合。之后对象若再次出现没有引用存在的情况，finalize()方法不会被再次调用，对象会直接变成不可触及的状态（一个对象finalize()方法只能被调用一次 )
public class TestFinalize {public static TestFinalize obj; //类变量，属于GC Root//此方法只能被调用一次@Overrideprotected void finalize() throws Throwable {super.finalize();System.out.println("调用当前类重写的finalize()方法");obj = this; //当前待回收的对象与引用脸上的一个对象obj建立了联系}public static void main(String[] args) throws InterruptedException {obj = new TestFinalize();obj = null;System.gc();System.out.println("第一次GC");Thread.sleep(2000);if (obj == null) {System.out.println("obj is dead");} else {System.out.println("obj is still alive");}System.out.println("第二次GC");obj = null;System.gc();Thread.sleep(2000);if (obj == null) {System.out.println("obj is dead");} else {System.out.println("obj is still alive");}}}
JProfile的GC Roots溯源
清除阶段
成功区分出存活对象或死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存
标记清除算法
Mark-Sweep，时间换空间
过程
- 内存被耗尽的时候，停止整个程序（STW，分析工作必须在一个可以保证一致性的快照中进行）
- 标记：从根节点开始遍历，标记所有被引用的对象，一般在对象的Header中记录为可达对象
- 清除：堆内存从头到尾进行遍历，发现对象在Header中没有被标记为可达对象，则将其回收。补充：这里的回收不是真的将其清除，而是把需要清除的对象的地址保存在空闲的地址表里，下次有新对象需要加载时，直接覆盖
优点
过程
内存中有两块区域（对应幸存者1区和幸存者2区），执行垃圾回收的时候，将1区中的有用对象复制到2区，清空1区；再次执行垃圾回收的时候，将2区中有用的对象复制到1区，再将2区清空；反复这个过程
优点
实现简单、运行高效
-
缺点
需要两倍的内存空间
- 维护更多引用地址，对于G1这种分拆称为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小
垃圾对象少（甚至所有的对象都不是垃圾对象时），就相当于平白无故将所有对象白白复制一遍
标记-压缩算法
标记-整理、Mark-Compact，常用于存活对象较多的年老区，移动式
执行过程
- 不需要维护空闲列表，只维护一个空闲内存起始地址
- 没有碎片问题
-
缺点
效率低于复制算法
- 维护引用可能较多，移动对象的同时如果对象被其他对象引用，则需要调整引用的地址
-
扩展
分代收集算法
背景
不同对象的生命周期不一样
-
分代
新生区区域较小、对象生命周期短、存活率低、回收频繁，因此采用复制算法
年老区区域较大、对象生命周期常、存活率高、回收不频繁，因此采用标记-清除或标记-压缩，或者混合实现
增量收集算法
背景
垃圾标记过程中需要停止用户线程，STW影响用户体验或者系统的稳定性，一次将所有垃圾清除会造成长时间的停顿
基本思想
基础仍是标记-清除或复制算法
通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作
缺点
垃圾回收过程中，间断性的执行应用程序代码
线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降
分区算法
一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次cc所产生的停顿。
- 分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。
每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。
System.gc()
```java public class TestGC2 {
public void method1() {
byte[] bytes = new byte[20 * 1024 * 1024];System.gc();
}
public void method2() {
byte[] bytes = new byte[20 * 1024 * 1024];bytes = null;System.gc();
}
public void method3() {
{byte[] bytes = new byte[10 * 1024 * 1024];}System.gc();
}
public void method4() {
{byte[] bytes = new byte[20 * 1024 * 1024];}int value = 1;System.gc();
}
public void method5() {
method1();System.gc();
}
}
- method1<br />[GC (System.gc()) [PSYoungGen: 2484K->712K(17920K)] 22964K->21200K(58880K), 0.0008897 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]<br />[Full GC (System.gc()) [PSYoungGen: 712K->0K(17920K)] [ParOldGen: 20488K->21105K(40960K)] 21200K->21105K(58880K), [Metaspace: 3292K->3292K(1056768K)], 0.0067263 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]- byte对象并没有被回收- method2<br />[GC (System.gc()) [PSYoungGen: 2484K->744K(17920K)] 22964K->21232K(58880K), 0.0007633 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]<br />[Full GC (System.gc()) [PSYoungGen: 744K->0K(17920K)] [ParOldGen: 20488K->625K(40960K)] 21232K->625K(58880K), [Metaspace: 3292K->3292K(1056768K)], 0.0037449 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]- 被回收了- method3<br />[GC (System.gc()) [PSYoungGen: 12724K->744K(17920K)] 12724K->10992K(58880K), 0.0058843 secs] [Times: user=0.03 sys=0.00, real=0.01 secs]<br />[Full GC (System.gc()) [PSYoungGen: 744K->0K(17920K)] [ParOldGen: 10248K->10865K(40960K)] 10992K->10865K(58880K), [Metaspace: 3292K->3292K(1056768K)], 0.0047046 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]- 没有回收，此时只是标记了bytes对象可以回收，但是要等到有数据覆盖，空间才能释放- method4<br />[GC (System.gc()) [PSYoungGen: 2484K->728K(17920K)] 22964K->21216K(58880K), 0.0009515 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]<br />[Full GC (System.gc()) [PSYoungGen: 728K->0K(17920K)] [ParOldGen: 20488K->625K(40960K)] 21216K->625K(58880K), [Metaspace: 3292K->3292K(1056768K)], 0.0040806 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]- 回收了- method5<br />[GC (System.gc()) [PSYoungGen: 2484K->760K(17920K)] 22964K->21248K(58880K), 0.0010739 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]<br />[Full GC (System.gc()) [PSYoungGen: 760K->0K(17920K)] [ParOldGen: 20488K->21105K(40960K)] 21248K->21105K(58880K), [Metaspace: 3292K->3292K(1056768K)], 0.0042074 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]<br />[GC (System.gc()) [PSYoungGen: 0K->0K(17920K)] 21105K->21105K(58880K), 0.0004051 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]<br />[Full GC (System.gc()) [PSYoungGen: 0K->0K(17920K)] [ParOldGen: 21105K->625K(40960K)] 21105K->625K(58880K), [Metaspace: 3292K->3292K(1056768K)], 0.0052610 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]- 两次GC，第一次是method1中的情况，第二次bytes不可达了，进行了回收<a name="bF6Sj"></a># 内存溢出与内存泄露<a name="kQOGg"></a>## 内存溢出OOM<a name="wKcvH"></a>### 是什么- 没有空闲内存- 进行了一次Full GC后仍然没有空闲内存<a name="ZG83g"></a>### 原因- Java虚拟机的堆内存设置不够- 创建了大量大对象，并且长时间不能被垃圾收集器收集（存在引用）<a name="U7pYD"></a>## 内存泄漏Memory Leak<a name="xj4no"></a>### 是什么- 也称存储泄漏，对象不再被用到，但是GC又不能回收- 宽泛意义上对象的生命周期过长导致的OOM也是内存泄漏，如静态属性- 内存泄漏会导致内存被逐步蚕食，最终出现OOM<a name="OtxAy"></a>### 举例- 单例模式可能导致内存泄漏- 需要关闭的资源未关闭，如数据库连接、网络连接和IO连接<a name="Uwk4g"></a># STW- Stop the world，GC事件发生过程中，停止用户线程时产生应用程序的停顿- 可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿- 分析工作必须在一个能确保一致性的快照中进行- 一致性指分析期间整个执行系统看起来像被冻结的某个事件点上- 如果出现分析过程中都存在引用关系还在不断变化，则分析结果的准确性无法保证- STW无法避免，只能尽量缩短暂停时间- 开发中不要使用System.gc(); 可能会导致STW<a name="ktD7m"></a># 垃圾回收的并行与并发<a name="yztxL"></a>## 并发Concurrent- 一个CPU来回切换不同的线程- 操作系统中，一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理器上运行- 并发并不是真正意义上的“同时进行”，只是CPU把一个时间段划分为几个时间片段，CPU在这几个时间区间之间来回切换，由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行。<a name="qW8wJ"></a>## 并行Parallel- 多个CPU各自执行不同的线程- 当系统有一个或以上CPU时，CPU执行不同的进程，进程之间不抢占CPU资源，称之为并行。- 取决于CPU的核心数量，而不是CPU数量<a name="WwEo3"></a>## 并行回收- 指多条垃圾收集线程并行工作，此时用户线程仍处于等待状态<a name="uADq7"></a>## 串行回收- 相较于并行的概念，单线程执行垃圾回收；如果内存不够则程序暂停，启动JVM垃圾回收期进行垃圾回收，回收完再启动程序的进程<a name="WIO07"></a>## 并发回收- 用户线程和垃圾收集线程同时执行（不一定是并行，可能会交替执行），垃圾回收线程在执行时不会停顿用户程序的运行。用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上，如GMS、G1<a name="iL87S"></a># 安全区域和安全点<a name="95731e12"></a>### 安全点- 程序执行的时候并不是在所有的时间点都可以停顿下来开始GC，只有特定位置才能停顿下来开始GC，这些位置称为安全点Safepoint- 安全点的选择很重要，如果太少可能导致等待GC的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。比如：选择一些执行时间较长的指令作为SafePoint，如方法调用、循环跳转和异常跳转。- 如果保证所有线程都在安全点停顿？- **抢先式中断**：先中断所有线程，如果还有线程不在安全点，就恢复线程，让线程跑到安全点。- **主动式中断**：设置一个中断标志，各个运行到安全点时主动轮询这个标志，如果标志为真则将自己运行中断挂起。<a name="9d951ac8"></a>### 安全区域- Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint 。但是，程序“不执行”的时候如线程处于sleep或blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域( Safe Region）来解决。- 安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把 safe Region看做是被扩展了的safepoint。- 实际执行：1. 当线程运行到safe Region的代码时，首先标识已经进入了Safe Region,如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程1. 当线程即将离开safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开safe Region的信号为止<a name="XqU9x"></a># 引用- 我们希望能描述这样一类对象:当内存空间还足够时，则能保留在内存中;如果内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象。- 【既偏门又非常高频的面试题】强引用、软引用、弱引用、虚引用有什么区别?具体使用场景是什么?- 在JDK 1.2版之后，Java对引用的概念进行了扩充，将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用（Weak Reference）和虚引用(Phantom Reference）4种，这4种引用强度依次逐渐减弱。- 除强引用外，其他3种引用均可以在java.lang.ref包中找到它们的身影。如下图显示了这3种引用类型对应的类，开发人员可以在应用程序中直接使用它们。<a name="bOl3S"></a>## 强引用- 在Java程序中，最常见的引用类型是强引用（普通系统99%以上都是强引用），也就是我们最常见的普通对象引用，也是默认的引用类型。- 当在Java语言中使用new操作符创建一个新的对象，并将其赋值给一个变量的时候，这个变量就成为指向该对象的一个强引用。- 强引用的对象是可触及的，垃圾收集器就永远不会回收掉被引用的对象。- 对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应（强）引用赋值为null，就是可以当做垃圾被收集了，当然具体回收时机还是要看垃圾收集策略。- 相对的，软引用、弱引用和虚引用的对象是软可触及、弱可触及和虚可触及的，在一定条件下，都是可以被回收的。所以，强引用是造成Java内存泄漏的主要原因之一。```javaObject obj = new Object(); //默认强引用
软引用
- 软引用是用来描述一些还有用，但非必需的对象。只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。
- 软引用通常用来实现内存敏感的缓存。比如：高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。
- 垃圾回收器在某个时刻决定回收软可达的对象的时候，会清理软引用，并可选地把引用存放到一个引用队列（Reference Queue) 。
类似弱引用，只不过Java虚拟机会尽量让软引用的存活时间长一些，迫不得已才清理
Object obj = new Object(); //默认强引用SoftReference<Object> sf = new SoftReference<Object>(obj);obj = null; //销毁强引用sf.get(); //获取原强引用对象
弱引用
弱引用也是用来描述那些非必需对象，只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。
- 但是，由于垃圾回收器的线程通常优先级很低，因此，并不一定能很快地发现持有弱引用的对象。在这种情况下，弱引用对象可以存在较长的时间。
- 弱引用和软引用一样，在构造弱引用时，也可以指定一个引用队列，当弱引用对象被回收时，就会加入指定的引用队列，通过这个队列可以跟踪对象的回收情况。
软引用、弱引用都非常适合来保存那些可有可无的缓存数据。如果这么做，系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。
虚引用
也称为“幽灵引用”或者“幻影引用”，是所有引用类型中最弱的一个。
- 一个对象是否有虚引用的存在，完全不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。
- 它不能单独使用，也无法通过虚引用来获取被引用的对象。当试图通过虚引用的get()方法取得对象时，总是null。
- 为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收过程。比如:能在这个对象被收集器回收时收到一个系统通知。
- 虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。
由于虚引用可以跟踪对象的回收时间，因此，也可以将一些资源释放操作放置在虚引用中执行和记录。
再谈GC分类
按线程数分
串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。
- 在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合，串行回收器的性能表现可以超过并行回收器和并发回收器。所以，串行回收默认被应用在客户端的client模式下的JVM中
- 在并发能力比较强的CPU上，并行回收器产生的停顿时间要短于串行回收器。
- 和串行回收相反，并行收集可以运用多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用了“stop-the-world”机制。
按工作模式分
- 并发式垃圾回收器 ：与应用程序线程交替工作，以尽可能减少应用程序的停顿时间
- 独占式垃圾回收器：一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束
按碎片处理方式分
- 压缩式垃圾回收器：在回收完成后，对存活对象进行压缩整理，消除回收后的碎片
-
按工作的内存区间分
新生区垃圾回收器
-
GC性能指标
吞吐量：运行用户代码的时间占总运行时间的比例
- 垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例
- 暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间(STW)
- 收集频率：相对于应用程序的执行，收集操作发生的频率
- 内存占用：Java堆区所占的内存大小
-
不可能三角
这三者共同构成一个“不可能三角”。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。
- 这三项里，暂停时间的重要性日益凸显。因为随着硬件发展，内存占用多些越来越能容忍，硬件性能的提升也有助于降低收集器运行时对应用程序的影响，即提高了吞吐量。而内存的扩大，对延迟反而带来负面效果。
-
吞吐量VS暂停时间
高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上，吞吐量越高程序运行越快。
- 低暂停时间（低延迟）较好因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型，有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此，具有低的较大暂停时间是非常重要的，特别是对于一个交互式应用程序。
- 不幸的是“高吞吐量”和“低暂停时间”是一对相互竞争的目标（矛盾）。
- 如果选择以吞吐量优先，那么必然需要降低内存回收的执行频率，但是这样会导致GC需要更长的暂停时间来执行内存回收。
- 如果选择以低延迟优先为原则，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。
在设计GC算法的时候，只能针对吞吐量或最小暂停时间的一种，现行标准：最大吞吐量优先的情况下，降低停顿时间。
垃圾回收期发展史
有了虚拟机，就一定需要收集垃圾的机制，这就是Garbage Collection，对应的产品我们称为Garbage Collector。
- 1999年随JDK1.3.1一起来的是串行方式的Serial GC ，它是第一款GC。ParNew垃圾收集器是serial收集器的多线程版本
- 2002年2月26日，Parallel GC 和concurrent Mark Sweep GC跟随JDK1.4.2一起发布
- Parallel GC在JDK6之后成为HotSpot默认GC。
- 2012年,在JDK1.7u4版本中，G1可用。
- 2017年，JDK9中G1变成默认的垃圾收集器，以替代CMS。
- 2018年3月，JDK10中G1垃圾回收器的并行完整垃圾回收，实现并行性来改善最坏情况下的延迟。
- 2018年9月，JDK11发布。引入Epsilon垃圾回收器，又被称为”No-Op(无操作）”回收器。同时，引入zGC:可伸缩的低延迟垃圾回收器(Experimental)。
- 2019年3月，JDK12发布。增强G1，自动返回未用堆内存给操作系统。同时，引入Shenandoah GC：低停顿时间的GC (Experimental)。
- 2019年9月，JDK13发布。增强ZGC，自动返回未用堆内存给操作系统。
2020年3月，JDK14发布。删除CMS垃圾回收器。扩展ZGC在macoS和windows上的应用
垃圾回收器分类
Serial回收器
Serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。
- Serial收集器作为Hotspot中client模式下的默认新生代垃圾收集器。serial 收集器采用复制算法、串行回收和STW机制执行内存回收。
- 除了年轻代之外，Serial收集器还提供用于执行老年代垃圾收集的Serial old收集器。Serial old收集器同样也采用了串行回收和STW机制，只不过内存回收算法使用的是标记-压缩算法。
- Serial old是运行在client模式下默认的老年代的垃圾回收器
- Serial old在server模式下主要有两个用途
- 与新生代的ParallelScavenge配合使用
- 作为老年代CMS收集器的后备垃圾收集方案
- 这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束(stop The world）
- 优势：对于单个CPU环境来说简单高效，没有与线程交互的开销，专心做垃圾收集
- -XX:+UseSerialGC：指定新生区和年老区都使用串行收集器Serial GC + Serial Old GC
ParNew回收器
- 可以看作是Serial的多线程版本，Par->Paraller，New->只处理新生区
- 适用于多CPU场景下，充分利用CPU资源，但是单CPU下效率并不比Serial收集器高
- 除了采用并行回收的方式回收内存，与Serial垃圾回收器几乎没有区别，也有STW，在很多Server端是JVM默认采用的新生区垃圾收集器。
Parallel回收器
- 新生区除了使用ParNew，还可以使用Parallel Scavenge收集器
- 同样采用复制算法、并行回收、STW机制
- 达到可控制的吞吐量，也被称为吞吐量优先的垃圾收集器，适应调节策略
- 高吞吐量：适合在后台运行而不需要与用户有过多交互的场景，如批量处理、订单处理、科学计算
- 提供Parallel Old收集器，代替年老区的Serial Old，同样采用标记-压缩算法，基于并行回收和STW机制
- Parallel Scavenge通常与Parallel Old搭配使用,作为JDK8的默认回收器
- 相关参数设置
- -XX:+UseParallelGC：新生区使用ParallelGC，开启后年老区默认使用ParallelOldGC
- -XX:+UseParallelOldGC：年老区使用ParallelOldGC，开启后新生区也使用ParallelGC
- -XX:+UseParallelGCThreads：设置新生区并行收集器的线程数，一般最好与CPU数量相同，避免过多的现车给数影响垃圾收集性能。CPU数量 ≤ 8，则ParallelGCTheads值等于CPU数量；当CPU数量 > 8时，ParallelGCTheads值等于 3 + [5*CPU_Count] / 8
- -XX:MaxGCPauseMillis：设置STW的最大时间，单位毫秒。收集器工作时会调整Java堆大小和其他参数。与高吞吐量对冲，STW越小则收集频率增高，吞吐量就变小了谨慎使用！
- -XX:GCTimeRatio：垃圾收集时间占总时间比例 = 1 / (N+1)；默认99，即垃圾收集时间占总运行时间的1%，与前一个参数有一定的矛盾性，暂停时间越长，Ratio参数就越容易超出设定比例
- -XX:+UseAdaptiveSizePolicy：设置Parallel Scavenge收集器具有自适应调节策略，会调整Eden区、Servivor区、年老区的空间比例，达到堆大小、吞吐量、停顿时间的最大平衡点，这也是为什么Eden:S1:S2在纸面上是8:1:1，而实际上是6:1:1
CMS回收器
- Concurrent-Mark-Sweep，主打低延迟，强交互应用使用，尽可能缩短STW的时间，提高用户体验
- HotSpot第一款并发收集器，第一次实现了让垃圾收集线程与用于线程同时工作
- 采用标记-清除算法，也有STW机制
- 无法与Parallel Scavenge收集器兼容使用，因此如果采用CMS，那新生区只能使用ParNew或Serial
- CMS不能等待年老区几乎填满才开始工作，达到一定阈值就必须开始工作，因为CMS与用户线程是并发执行的（即要留有预期的空间给用户线程使用。如果垃圾产生速度>回收速度，则会报Concurrent Mode Filure，这时虚拟机启动后备方案：临时启用Serial Old垃圾收集器收集年老区。
- 弊端：
- 采用标记-清除算法，内存碎片不可避免，不能采用指针碰撞技术分配内存空间，只能选择空闲列表执行内存分配。
- 对CPU资源非常敏感，会因为占用一部分线程导致总吞吐量降低
- 无法收集浮动垃圾，因为用户线程运行过程中会产生新的垃圾，这些垃圾没有被标记，清理阶段也不会被清理
- 为什么是标记-清除：因为垃圾回收线程与用户线程并发执行，在执行过程中不能修改对象的地址！
- 相关参数设置
- -XX:+UseConcMarkSweepGC：手动使用CMS，开启后垃圾收集器组合会变为 ParNew + CMS + Serial Old
- -XX:CMSInitiatingOccupanyFraction：堆内存达到整个阈值就开始进行垃圾回收，JDK5为68，JDK6及以后为92。如果内存增长缓慢，可以设置较大的阈值，大的阈值可以降低CMS触发频率，但是过大又可能触发Serial Old，因此通过该选项可以有效降低Full GC的执行次数。
- -XX:+UseCMSCompactAtFullCollection：指定执行完Full GC后对内存空间进行压缩整理
- -XX:CMSFullGCsBeforeCompaction：执行多少次Full GC后对内存进行整理
- -XX:ParallelCMSThreads：设置CMS的线程数量，默认 (ParallelGCThreads + 3) / 4，ParallelGCThreads 指新生区并行收集器的线程数，CPU紧张时，应用程序的性能会非常糟糕。
G1回收器
- JDK9及以后的默认垃圾回收器，面向服务器端，适应不断扩大的内存和不断增加的处理器数量，进一步降低STW的时长，同时兼容良好的吞吐量，目标是“全功能收集器”。
- G1是一个并行回收器，把堆内存分割为不相关的区域（Region），使用不同的Region表示Eden、S1、S2、Old，为避免全区域垃圾回收，跟踪各个Region里垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region
- 优点
- 并行：G1在回收期间可以有多个GC线程同时工作，有效利用多核计算能力。
- 并发：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行
- 分代收集：区分新生区和年老区，不要求这些区是连续的，也不再坚持固定大小和固定数量，同时兼顾新生区和年老区。
- 空间整合：内存的回收以region为基本单位，region之间是复制算法，整体可以看作是标记-压缩算法，可以避免内存碎片，有利于长时间运行，分配空间的时候不会因为无法找到连续内存空间而触发GC。当堆内存非常大的时候，G1的优势更加明显。
- 可预测的停顿时间模型（软实时soft real-time）：除了低停顿，还可以建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超过N毫秒。由于分区，G1可以选取部分区域进行内存回收，这样就缩小了回收的范围，对于全局停顿可以有较好的控制。
- 缺点：相比CMS，G1在应用程序运行过程中，G1无论是为了垃圾收集产生的内存占用还是程序运行时的额外执行负载，都比较高。经验上来说，小内存应用在CMS的表现大概率会由于G1，而在大内存上G1可以发挥其优势，平衡点在6-8GB之间。
- 相关参数
- -XX:+UseG1GC：指定使用G1垃圾回收器，JDK9开始为默认垃圾收集器
- -XX:G1HeapRegionSize：设置每个Region的大小，值为2的幂，1-32MB之间，目标是划分出约2048个区域，默认是堆内存的1/2000
- -XX:MaxGCPauseMillis：设置期望达到的最大GC停顿时间，默认200ms，设置过低可能造成只回收有价值的Region，其他的不进行回收，长时间运行造成OOM
- -XX:ParallelGCThread：设置STW工程线程数的值，最多设置8
- -XX:ConcGCThreads：设置并发标记的线程数，将n设置为并行垃圾回收线程数(ParallelGCThreads)的1/4左右
- -XX:InitiatingHeapOccupancyPercent：设置触发并发GC周期的Java堆内存占用率阈值，超过此值就会触发GC（开始年老区标记，而不是清除垃圾），默认是45
- 适用场景
- 服务器端、具有大内存、多处理器的机器
- 最主要的应用是需要低GC延迟，并具有大内存的应用程序提供解决方案
- 堆大小在6GB或更大时，可预测的暂停时间可以低于0.5秒
- 替换JDK1.5中的CMS收集器，前提：超过50%的Java堆被活动数据占用，对象分配频率或年代提升频率变化很大，GC停顿时间过长
- 可以采用应用线程承担后台运行GC工作（可能会影响吞吐量）
- Region使用介绍
- 将整个Java堆划分为2048个大小相同的独立Region块，每个Region块1-32MB，可以通过-XX:G1HeapRegionSize设定
- 所有的Region大小相同，且在JVM生命周期内不会被改变
- 新生区和年老区不再是物理隔离，它们都是一部分Region的集合，通过Region的动态分配方式实现逻辑上的连接
- 除了Eden、Survivor、Old内存区域，新增了一种内存区域Humongous，主要用于存储大对象，如果超过0.5个Region，就放到H，如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储，如果找不到，则启动Full GC
- 记忆集Remember Set
- 一个对象可能被不同区的对象引用，如果年老区引用了新生区的对象，那么判断对象存活时需要扫描整个Java堆，这样就会降低Minor GC的效率
- 无论G1还是其他分代收集器，JVM都是使用Remembered set来避免全局扫描：每个Region都有一个对应的Remembered Set;
- 每次Reference类型数据写操作时，都会产生一个write Barrier（写屏障）暂时中断操作;
- 然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region(其他收集器:检查老年代对象是否引用了新生代对象）﹔
- 如果不同，通过cardTable把相关引用信息记录到引用指向对象的所在Region对应Remembered set中;
- 当进行垃圾收集时，在GC根节点的枚举范围加入Remembered Set，就可以保证不进行全局扫描，也不会有遗漏。
垃圾回收过程
- 新生区（Young GC）
- 扫描根，static变量、正在执行的方法调用链条上的局部变量等，根引用联通Rset记录的外部引用作为扫描存活对象的入口
- 更新Rset：准确反映年老区所在的内存分段中对象的引用
- 处理Rset：这些被指向的Eden中的对象被认为是存活的对象
- 复制对象：Eden + from -> to
- 处理强软弱虚各种引用，最终Eden变为空
- 年老区并发标记过程（Concurrent Marking）
- 初始标记：标记根节点直接可达的对象，STW
- 根区域扫描：G1扫描Survivor区直接可达的年老区对象，并标记被引用的对象
- 并发标记：整个堆总进行并发标记，若发现区域中所有对象都是垃圾，则整个区域被立即回收，同时会计算每个区域的对象活性
- 再次标记：对上一次的标记结果进行一些修正和补充，STW
- 独占清理：计算各个区域存活对象和GC回收比例，并进行排序，STW
- 并发清理：识别并清理完全空闲的区域
- 混合回收（Mixed GC）
- 并发标记结束后，年老区百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算出来，默认情况下，这些年老区的内存分段会分8次（可通过-XX:G1MixedGCCountTarget设置）被回收
- 混合回收的回收集包括八分之一的年老区内存分段，Eden区分段，Survivor区内存分段
- 垃圾占内存分段比例越高的，越先被回收，并且有一个阈值决定内存分段是否被回收（-XX:G1MixedGCLiveThresholdPercent，默认65%）
- 混合回收不一定要进行8次，可以设置阈值（-XX:G1HeapWastePercent，默认10%）来决定低于可回收的垃圾占堆内存的多少就不再进行混合回收，因为不值得花费很多的时间回收很少的内存
- Full GC
- 新生区（Young GC）
-
垃圾回收器组合
ParNew+SerialOld
对于新生区，回收次数频繁，采用并行的方式比较高效
- 对于年老区，回收次数少，采用串行方式节省资源（CPU并行需要切换线程，消耗额外资源）
-XX:+UseParNewGC：手动指定使用ParNew收集器，-XX:ParallelGCThreads可以限定线程数量，默认开启数量和CPU个数相同
Parallel Scavenge+Parallel Old
ParaNew/Serial+CMS+Serial Old
各阶段
-
多核、高吞吐量
-
多核、低停顿
-
多核、大内存
-
新发展
G1 GC不断进行改进，JDK10以后，Full GC已经是并行运行了，在很多场景下表现还略优于Parallel GC的并行Full GC
- 得益于开销非常小，在Serverless等新的应用场景下，Serial GC找到了新的舞台
- CMS GC由于算法的理论缺陷，在JDK14中已移除
- Epsilon垃圾回收器，No-OP，只管内存分配，运行后就退出了
- Shenandoah GC：主打低停顿时间
- ZGC
- 提高吞吐量的情况下，尽可能限制垃圾收集的停顿时间在十毫秒以内。
- 基于Region内存布局，不设分代，使用了读屏障、染色指针和内存多重映射等技术实现可并发的标记-压缩算法，以低延迟为首要目标。
- 并发标记 - 并发预备重分配 - 并发重分配 - 并发重映射
- 几乎在所有地方都是并发执行的，除了初始标记的是STW的
- -XX:+UnlockExperimentalVMOptions -XX:+UseZGC
若有收获，就点个赞吧
0 人点赞
