JVM垃圾回收GarbageCollect

如何确定一个对象是垃圾？

　　要想进行垃圾回收，得先知道什么样的对象是垃圾。

引用计数法：

　　对于某个对象而言，只要应用程序中持有该对象的引用，就说明该对象不是垃圾，如果一个对象没有任何指针对其引用，它就是垃圾。

　　弊端 :如果AB相互持有引用，导致永远不能被回收。

可达性分析：

　　通过GC Root的对象，开始向下寻找，看某个对象是否可达。

　　能作为GC Root:类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量等。

垃圾收集算法：

　　已经能够确定一个对象为垃圾之后，接下来要考虑的就是回收，怎么回收呢？得要有对应的算法，下面聊聊常见的垃圾回收算法。

标记-清除(Mark-Sweep)：

　　标记：找出内存中需要回收的对象，并且把它们标记出来。此时堆中所有的对象都会被扫描一遍，从而才能确定需要回收的对象，比较耗时。

　　清除:清除掉被标记需要回收的对象，释放出对应的内存空间。

　　缺点：

1. 标记和清除两个过程都比较耗时，效率不高
2. 会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

复制(Copying)：

　　将内存划分为两块相等的区域（S0,S1），每次只使用其中一块，如下图所示：

　　当其中一块内存使用完了，就将还存活的对象复制到另外一块上面，然后把已经使用过的内存空间一次清除掉。

　　缺点: 空间利用率降低。

标记-整理(Mark-Compact):

　　标记过程仍然与"标记-清除"算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

　　让所有存活的对象都向一端移动，清理掉边界意外的内存。

分代收集算法：既然上面介绍了3中垃圾收集算法，那么在堆内存中到底用哪一个呢？

1. Young区：复制算法(对象在被分配之后，可能生命周期比较短，Young区复制效率比较高)
2. Old区：标记清除或标记整理(Old区对象存活时间比较长，复制来复制去没必要，不如做个标记再清理)

垃圾收集器:

　　如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现，说白了就是落地咯。

1. 串行收集器Serial:Serial、Serial Old：一个线程跑，停止，启动垃圾回收线程，回收完成，继续执行刚才暂停的线程。适用于内存比较小的嵌入式设备中。
2. 并行收集器Parallel:Parallel Scavenge、Parallel Old，吞吐量优先，多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态，适合科学计算、后台处理等弱交互场景。
3. 并发收集器Concurrent:CMS、G1，停顿时间优先，用户线程和垃圾收集线程同时执行(但不一定是并行的，可能会交替执行)，垃圾收集线程在执行的时候不会停顿用户程序的运行。适合于对相应时间有要求的场景，比如Web。

Serial收集器:

　　Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK1.3.1之前）是虚拟机新生代收集的唯一选择。它是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是其在进行垃圾收集的时候需要暂停其他线程。

• 优点：简单高效，拥有很高的单线程收集效率
• 缺点：收集过程需要暂停所有线程
• 算法：复制算法
• 适用范围：新生代
• 应用：Client模式下的默认新生代收集器

ParNew收集器：

　　可以把这个收集器理解为Serial收集器的多线程版本。

• 优点：在多CPU时，比Serial效率高。
• 缺点：收集过程暂停所有应用程序线程，单CPU时比Serial效率差。
• 算法：复制算法
• 适用范围：新生代
• 应用：运行在Server模式下的虚拟机中首选的新生代收集器

Parallel Scavenge收集器：

　　Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew一样，但是Parallel Scanvenge更关注 系统的吞吐量 。吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)。比如虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量=(100-1)/100=99%。若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务。

　　-XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间，-XX:GCTimeRatio直接设置吞吐量的大小。

Serial Old收集器：

　　Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用"标记-整理算法"，运行过程和Serial收集器一样。

Parallel Old收集器：

　　Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和"标记-整理算法"进行垃圾回收。吞吐量优先

CMS收集器：

　　CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间 为目标的收集器。采用的是"标记-清除算法",整个过程分为4步

1. 初始标记 CMS initial mark ，标记GC Roots能关联到的对象 Stop The World--->速度很快。
2. 并发标记 CMS concurrent mark，进行GC Roots跟踪（GC Roots Tracing）。
3. 重新标记 CMS remark， 修改并发标记因用户程序变动的内容 Stop The World。
4. 并发清除 CMS concurrent sweep。

　　由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。

• 优点：并发收集、低停顿
• 缺点：产生大量空间碎片、并发阶段会降低吞吐量

G1收集器：

　　并行与并发，分代收集（仍然保留了分代的概念），空间整合（整体上属于“标记-整理”算法，不会导致空间碎片），可预测的停顿（比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内-XX:MaxGCPauseMillis=200ms，消耗在垃圾收集上的时间不得超过N毫秒，如果设置了停顿时间0.01秒，那么如下图所示，再筛选回收前已经停顿了0.01秒，那么筛选回收将不执行来满足我们设置得停顿时间。设置的太小也是不合理的，导致垃圾回收不及时。会OOM异常）。使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

1. 初始标记（Initial Marking）   标记一下GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程。
2. 并发标记（Concurrent Marking）  从GC Roots进行可达性分析，找出存活的对象，与用户线程并发执行。
3. 最终标记（Final Marking）    修正在并发标记阶段因为用户程序的并发执行导致变动的数据，需暂停用户线程。
4. 筛选回收（Live Data Counting and Evacuation） 对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间制定回收计划。

　　JDK 7开始使用，JDK 8非常成熟，JDK 9默认的垃圾收集器，适用于新老生代。

1. jdk1.7 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）
2. jdk1.8 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）
3. jdk1.9 默认垃圾收集器G1
4. jdk11 开始引入ZGC，ZGC全称是Z Garbage Collector，是一款可伸缩(scalable)的低延迟(low latency garbage)、并发(concurrent)垃圾回收器，旨在实现以下几个目标：停顿时间不超过10ms，停顿时间不随heap大小或存活对象大小增大而增大，可以处理从几百兆到几T的内存大。

　　判断是否需要使用G1收集器？

• 50%以上的堆被存活对象占用
• 对象分配和晋升的速度变化非常大
• 垃圾回收时间比较长

理解吞吐量和停顿时间：

• 停顿时间：垃圾收集器 进行 垃圾回收终端应用执行响应的时间
• 吞吐量：运行用户代码时间/(运行用户代码时间+垃圾收集时间)

　　停顿时间越短就越适合需要和用户交互的程序，良好的响应速度能提升用户体验；高吞吐量则可以高效地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

　　小结 :这两个指标也是评价垃圾回收器好处的标准，其实调优也就是在观察者两个变量。

如何选择合适的垃圾收集器：

　　官网 ：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref28

　　Java HotSpot VM包括三种不同类型的收集器，每种收集器具有不同的性能特征。

• 串行收集器使用单个线程来执行所有垃圾收集工作，这使之相对高效，因为线程之间没有通信开销。它最适合单处理器计算机，因为它不能利用多处理器硬件，尽管它在多处理器上对于数据集较小（大约100 MB）的应用很有用。默认情况下，在某些硬件和操作系统配置上选择了串行收集器，或者可以使用选项显式启用串行收集器-XX:+UseSerialGC。
• 并行收集器（也称为吞吐量收集器）并行执行次要收集，这可以大大减少垃圾收集的开销。它适用于具有在多处理器或多线程硬件上运行的中型到大型数据集的应用程序。默认情况下，在某些硬件和操作系统配置上选择了并行收集器，或者可以使用选项显式启用并行收集器-XX:+UseParallelGC。并行压缩是使并行收集器能够并行执行主要收集的功能。如果没有并行压缩，则使用单个线程执行主要集合，这会大大限制可伸缩性。如果-XX:+UseParallelGC指定了该选项，则默认情况下启用并行压缩。将其关闭的选项是-XX:-UseParallelOldGC。
• 大多数并发的收集器会同时执行其大部分工作（例如，在应用程序仍在运行时），以使垃圾收集暂停时间较短。它设计用于具有中型到大型数据集的应用程序，在这些应用程序中，响应时间比整体吞吐量更重要，因为用于最小化暂停的技术会降低应用程序性能。Java HotSpot VM提供了两个主要是并发收集器之间的选择。使用该选项-XX:+UseConcMarkSweepGC启用CMS收集器或-XX:+UseG1GC启用G1收集器。

　　优先调整堆的大小让服务器自己来选择。如果性能仍然不能达到您的目标，请使用以下准则作为选择收集器的起点。

• 如果应用程序的数据集较小（最大约100 MB），则使用选项选择串行收集器-XX:+UseSerialGC。

• 如果应用程序将在单个处理器上运行，并且没有暂停时间要求，则让VM选择收集器，或使用选项选择串行收集器-XX:+UseSerialGC。

• 如果应用程序性能是第一要务，并且没有暂停时间要求或可接受的暂停时间为1秒或更长时间，则让VM选择收集器，或使用选择并行收集器-XX:+UseParallelGC。

• 如果响应时间比整体吞吐量更重要，并且垃圾收集暂停时间必须保持小于1秒，那么请使用-XX:+UseConcMarkSweepGC或选择并发收集器-XX:+UseG1GC。

　　这些准则仅提供选择收集器的起点，因为性能取决于堆的大小，应用程序维护的实时数据量以及可用处理器的数量和速度。暂停时间对这些因素特别敏感，因此前面提到的1秒阈值仅是近似值：在许多数据大小和硬件组合上，并行收集器的暂停时间将超过1秒。相反，在某些组合上，并发收集器可能无法将暂停时间保持在1秒以内。如果推荐的收集器未达到所需的性能，请首先尝试调整堆和代大小以满足所需的目标。如果性能仍然不足，请尝试使用其他收集器：使用并发收集器减少暂停时间，并使用并行收集器增加多处理器硬件上的总体吞吐量。

如何开启需要的垃圾收集器：

1. 串行
   1. -XX：+UseSerialGC
   2.  -XX：+UseSerialOldGC
2. 并行(吞吐量优先)：
   1. -XX：+UseParallelGC
   2. -XX：+UseParallelOldGC
3. 并发收集器(响应时间优先)
   1. -XX：+UseConcMarkSweepGC
   2. -XX：+UseG1GC