JVM-垃圾回收(垃圾回收的相关概念,垃圾收集器概述)(4)

垃圾回收的相关概念:

1.System.gc() 的理解

在默认情况下，通过 System.gc()者 Runtime.getRuntime().gc() 的调用，会显式触发 Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。

然而 System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用(不能 确保立即生效)。

JVM 实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。而一般情况 下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，我们可以在运行之间调用System.gc()。

(调用System.gc()方法会触发Gull GC (整堆收集),但是调用后不一定会立即生效,因为垃圾回收是自动的,一般情况下,不要在项目中显示的调用.)

2.Stop the World

Stop-the-World，简称 STW，指的是 GC 事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为 STW。

可达性分析算法中枚举根节点（GC Roots）会导致所有 Java 执行线程停顿，为 什么需要停顿所有 Java 执行线程呢？
1.分析工作必须在一个能确保一致性的快照中进行
2.一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
3.如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证
4.被 STW 中断的应用程序线程会在完成 GC 之后恢复，频繁中断会让用户感觉
5.像是网速不快造成电影卡带一样，所以我们需要减少 STW 的发生。
6.STW 事件和采用哪款 GC 无关，所有的 GC 都有这个事件。
7.越优秀，回收效率越来越高，尽可能地缩短了暂停时间。

STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。

( Stop the World -->STW 在垃圾回收时,会导致整个应用程序停止.
在标记垃圾对象时,需要以某个时间节点上内存中的情况进行分析(拍照 快照)
因为不进行停顿的话,内存中的对象不停的变化,导致分析结果不准确.
停顿是不可避免的,优秀的垃圾回收器尽可能减少停顿的时间.)

3.对象引用

我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存中；如果 内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象。

在 JDK1.2 版之后，Java 对引用的概念进行了扩充，将引用分为：
强引用（Strong Reference）
软引用（Soft Reference）
弱引用（Weak Reference）
虚引用（Phantom Reference）
这4种引用强度依次逐渐减弱。除强引用外，其他3种引用均可以在java.lang.ref 包中找到它们的身影。如下图，显示了这 3 种引用类型对应的类，开发人员可以 在应用程序中直接使用它们.

强引用（StrongReference）：
最传统的“引用”的定义，是指在程序代码之 中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。 无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用 的对象。宁可报 OOM，也不会 GC 强引用

软引用（SoftReference）：在系统将要发生内存溢出之前，将会把这些对象列 入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出 内存溢出异常。

弱引用（WeakReference）：被弱引用关联的对象只能生存到下一次垃圾收集 之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联 的对象。

虚引用（PhantomReference）：一个对象是否有虚引用的存在，完全不会对 其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设 置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

(对象引用:
Object obj = new Object();
就是将对象分等级: 强引用(有引用指向的对象) 软引用 弱引用 虚引用(都是垃圾了)
强引用: Object obj = new Object(); obj引用创建的对象 那么此对象就是被强引用的.
​ 这种情况下,即使内存不够用了,报内存溢出,也不会回收.
软引用: 当内存足够使用时,先不回收这类对象,当虚拟机内存不够用时,要回收此类对象.
弱引用: 此类对象只能生存到下次垃圾回收时, 只要发生垃圾回收,就会回收此类对象.
虚引用: 发现即回收.)

垃圾回收器:

1.垃圾回收器概述

如果说收集算法是内存回收的方法论,那么收集器就是内存回收的实践者.
垃圾收集器没有在 java 虚拟机规范中进行过多的规定，可以由不同的厂商、 不同版本的 JVM 来实现。
由于 JDK 的版本处于高速迭代过程中，因此 Java 发展至今已经衍生了众多 的 GC 版本。
从不同角度分析垃圾收集器，可以将 GC 分为不同的类型。

垃圾回收器(具体实现垃圾回收的收集器名称)

2.垃圾回收器分类

一.按线程数分，可以分为(单线程)串行垃圾回收器和(多线程)并行垃圾回收器。

单线程垃圾回收器(Serial)
只有一个线程进行垃圾回收,使用于小型简单的使用场景,垃圾回收时,其他用户线程会暂停.

多线程垃圾回收器

多线程垃圾回收器内部提供多个线程进行垃圾回收,在多 cpu 情况下大大提升垃 圾回收效率,但同样也是会暂停其他用户线程.

二.按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器。

并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。

独占式垃圾回收器（stop the world）一旦运行，就停止应用程序中的所有 用户线程，直到垃圾回收过程完全结束。

三.按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器。

(按线程数分，可以分为串行垃圾回收器和并行垃圾回收器
按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器
按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器)

3.GC 性能指标

吞吐量：运行用户代码的时间占总运行时间的比例（总运行时间：程序的运 行时间+内存回收的时间）
垃圾收集开销：垃圾收集所用时间与总运行时间的比例。
暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。
收集频率：相对于应用程序的执行，收集操作发生的频率。
内存占用：Java 堆区所占的内存大小。
快速：一个对象从诞生到被回收所经历的时间

4.常见的垃圾收集器

串行回收器：Serial ; Serial old ;
并行回收器：ParNew ; Parallel scavenge ; Parallel old ;
并发回收器：CMS ; G1 ;

新生代收集器：Serial ; ParNew ; Parallel scavenge；
老年代收集器：Serial old ; Parallel old ; CMS；
整堆收集器：G1；

图中展示了 7 种作用于不同分代的收集器，如果两个收集器之间存在连线， 则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。

4.1.CMS 回收器(低延迟)

CMS(Concurrent Mark Sweep，并发标记清除)收集器是以获取最短回收停顿 时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并 发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。

垃圾回收过程:

初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直 接关联的对象进行标记。

并发标记：使用多条标记线程，与用户线程并发执行。此过程进行可达性分析， 标记出所有废弃对象。速度很慢。

重新标记：Stop The World，使用多条标记线程并发执行，将刚才并发标记过 程中新出现的废弃对象标记出来。

并发清除：只使用一条 GC 线程，与用户线程并发执行，清除刚才标记的对象。 这个过程非常耗时。

并发标记与并发清除过程耗时最长，且可以与用户线程一起工作，因此，总体上 说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。

CMS 的优点： 并发收集 低延迟

CMS 的弊端：
1.CMS是基于标记–清除算法来实现的,会产生内存碎片.

2.CMS在并发阶段,它虽然不会导致用户线程停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量会降低.

3.CMS收集器无法处理浮动垃圾( floating garbage )

4.2三色标记法:

三色标记法将对象的颜色分为了黑、灰、白，三种颜色。

黑色:该对象已经被标记过了，且该对象下的属性也全部都被标记过了,例如 GCRoots 对象。

灰色:对象已经被垃圾收集器扫描过了，但是对象中还存在没有扫描的引用(GC 需要从此对象中去寻找垃圾);

白色:表示对象没有被垃圾收集器访问过，即表示不可达.

三色标记的过程::
为了解决并发的问题，引入中间状态(灰色)，当一个对象被标记的时候，会有下 面几个过程：

1.刚开始，确定为 GC Roots 的对象为黑色。

2.将 GC Roots 直接关联的对象置为灰色。

3.遍历灰色对象的所有引用，灰色对象本身置为黑色，其引用置为灰色。

4.重复步骤 3，直到没有灰色对象为止。

5.结束时，黑色对象存活，白色对象回收。

这个过程正确执行的前提是没有其他线程改变对象间的引用关系，然而，并发标记的过程中，用户线程仍在运行，因此就会产生漏标和错标的情况。

漏标:

假设 GC 已经在遍历对象 B 了，而此时用户线程执行了 A.B=null 的操作，切断了 A 到 B 的引用:

本来执行了 A.B=null 之后，B、D、E 都可以被回收了，但是由于 B 已经变为灰色，它仍会被当做存活对象，继续遍历下去。最终的结果就是本轮 GC 不会回收 B、D、E，留到下次 GC 时回收，也算是浮动垃圾的一部分。

错标:
假设 GC 线程已经遍历到 B 了，此时用户线程执行了以下操作：
B.D=null; //B 到 D 的引用被切断
A.xx=D; //A 到 D 的引用被建立

B 到 D 的引用被切断，且 A 到 D 的引用被建立。
此时 GC 线程继续工作，由于 B 不再引用 D 了，尽管 A 又引用了 D，但是因为 A 已经标记为黑色，GC 不会再遍历 A 了，所以 D 会被标记为白色，最后被当做垃圾回收。
可以看到错标的结果比漏标严重的多，浮动垃圾可以下次 GC 清理，而把不该回收的对象回收掉，将会造成程序运行错误.

解决错标的问题:

错标只有在满足下面两种情况下才会发生：

只要打破任一条件，就可以解决错标的问题。

原始快照和增量更新

原始快照打破的是第一个条件：当灰色对象指向白色对象的引用被断开时，就将这条引用关系记录下来。当扫描结束后，再以这些灰色对象为根，重新扫描一次。

增量更新打破的是第二个条件：当黑色指向白色的引用被建立时，就将这个新的引用关系记录下来，等扫描结束后，再以这些记录中的黑色对象为根，重新扫描 一次。相当于黑色对象一旦建立了指向白色对象的引用，就会变为灰色对象。

总结:

CMS 为了让 GC 线程和用户线程一起工作，回收的算法和过程比以前旧的收集 器要复杂很多。究其原因，就是因为 GC 标记对象的同时，用户线程还在修改对 象的引用关系。因此 CMS 引入了三色算法，将对象标记为黑、灰、白三种颜色 的对象，将用户线程修改的引用关系记录下来，以便在「重新标记」阶段可以修正对象的引用。

虽然 CMS 从来没有被 JDK 当做默认的垃圾收集器，存在很多的缺点，但是它开 启了「GC 并发收集」的先河，为后面的收集器提供了思路。

4.3.G1(Garbage First)回收器(区域划分代式)

应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有 GC 就不能保证应用程序正常进行，而经常造成 STW 的 GC 又跟不上实际的需求，所以才会不断地尝试对 GC 进行优化。

G1（Garbage-First）垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器，是当今收集器技术发展的 最前沿成果之一. 与此同时，为了适应现在不断扩大的内存和不断增加的处理器数量，进一步 降低暂停时间（pause time），同时兼顾良好的吞吐量。

官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以 才担当起“全功能收集器”的重任与期望。

G1 是一款面向服务端应用的垃圾收集器。

为什么名字叫做 Garbage First（G1）呢？

因为 G1 是一个并行回收器，它把堆内存分割为很多不相关的区域（Region） （物理上不连续的）。使用不同的 Region 来表示 Eden、幸存者 0 区，幸存者 1 区，老年代等。

G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各 个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时 间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收 价值最大的 Region.

由于这种方式的侧重点在于回收垃圾最大量的区间（Region），所以我们给 G1 一个名字：垃圾优先（Garbage First）。

G1（Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备 多核 CPU 及大容量内存的机器，以极高概率满足 Gc 停顿时间的同时，还兼具 高吞吐量的性能特征。

G1 收集器可以 “ 建立可预测的停顿时间模型 ”，它维护了一个列表用 于记录每个 Region 回收的价值大小（回收后获得的空间大小以及回收所需时 间的经验值），这样可以保证 G1 收集器在有限的时间内可以获得最大的回收效率.

G1 收集器收集器收集过程有初始标记、并发标记、最终标记、 筛选回收，和 CMS 收集器前几步的收集过程很相似：

① 初始标记：标记出 GC Roots 直接关联的对象，这个阶段速度较快，需 要停止用户线程，单线程执行。
② 并发标记：从 GC Root 开始对堆中的对象进行可达新分析，找出存活 对象，这个阶段耗时较长，但可以和用户线程并发执行。
③ 最终标记：修正在并发标记阶段引用户程序执行而产生变动的标记记录。
④ 筛选回收：筛选回收阶段会对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来指定回收计划（用最少的时间来回收包 含垃圾最多的区域，这就是 Garbage First 的由来——第一时间清理垃圾最多 的区块），这里为了提高回收效率，并没有采用和用户线程并发执行的方式，而是停顿用户线程。

适用场景：要求尽可能可控 GC 停顿时间；内存占用较大的应用。可以用 -XX:+UseG1GC 使用 G1 收集器，jdk9 默认使用 G1 收集器。

4.4 查看 JVM 垃圾回收器设置垃圾回收器

打印默认垃圾回收器:

-XX:+PrintCommandLineFlags -version

JDK 8 默认的垃圾回收器:

年轻代使用 Parallel Scavenge GC

老年代使用 Parallel Old GC

打印垃圾回收详细信息:

-XX:+PrintGCDetails -version

设置默认垃圾回收器:

Serial 回收器:
-XX:+UseSerialGC 年轻代使用 Serial GC， 老年代使用 Serial Old GC

ParNew 回收器:
-XX:+UseParNewGC 年轻代使用 ParNew GC,不影响老年代。

CMS 回收器:
-XX:+UseConcMarkSweepGC 老年代使用 CMS GC。

G1 回收器:
-XX:+UseG1GC 手动指定使用 G1 收集器执行内存回收任务。
-XX:G1HeapRegionSize 设置每个 Region(区域) 的大小。