1 GC的分类与性能指标

• 垃圾收集器没有在规范中进行过多的规定，可以由不同的厂商、不同版本的JVM来实现。
• 由于JDK的版本处于高速迭代过程中，因此Java发展至今已经衍生了众多的GC版本。
• 从不同角度分析垃圾收集器，可以将GC分为不同的类型。

1.1 按线程数分，可以分为串行垃圾回收器和并行垃圾回收器

• 串行回收指同一个时间段内，只允许一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直到垃圾收集工作结束
  • 在单CPU处理器或者较小应用内存等硬件平台不是特别优越的场合，串行回收器的性能表现可以超过并行回收器和并发回收器。所以串行回收默认被应用在客户端的client模式下的JVM中
  • 在并发能力比较强的CPU上，并行回收器产生的停顿时间要短于串行回收器
• 和串行相反，并行收集可以运用在多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用了STW机制

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

• 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间。
• 独占式垃圾回收器（Stop the world）一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束。

1.3 按碎片处理方式分，可分为压缩式垃圾回收器和非压缩式垃圾回收器

• 压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整理，消除回收后的碎片。
  • 再分配对象空间使用: 指针碰撞
• 非压缩式的垃圾回收器不进行这步操作。
  • 再分配对象空间使用: 空闲列表

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

1.5 评估GC的性能指标

吞吐量

• 运行用户代码的时间占总运行时间的比例
• 总运行时间：程序的运行时间十内存回收的时间
• 吞吐量优先，意味着单位时间内，STW的时间最短

垃圾收集开销

• 吞吐量的补数，垃圾收集所用时间与总运行时间的比例

暂停时间

• 执行垃圾收集时，程序的工作线程被暂停的时间

收集频率

• 相对于应用程序的执行，收集操作发生的频率

内存占用

• Java堆区所占的内存大小

快速

• 一个对象从诞生到被回收所经历的时间

1.6 不可能三角

• 简单来说抓住两点，吞吐量和暂停时间
• 高吞吐量与低暂停时间，是一对互相竞争的。因为如果高吞吐量优先，必然需要降低内存回收的执行频率，导致GC需要更长的暂停时间来执行内存回收。
• 如果选择低延迟优先为原则，也只能频繁的执行内存回收，引起程序吞吐量的下降

详解

• 吞吐量：吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/ （运行用户代码时间+垃圾收集时间）
  • 比如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%
  • 这种情况下，应用程序能容忍较高的暂停时间，因此，高吞吐量的应用程序有更长的时间基准，快速响应是不必考虑的
  • 吞吐量优先，意味着在单位时间内，STW的时间最短。 0.2 + 0.2 = 0.4
• 暂停时间：“暂停时间”是指一个时间段内应用程序线程暂停，让GC线程执行的状态
  • 例如，GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的
  • 暂停时间优先，意味着尽可能让单次STW的时间最短。 0.1 + 0.1 + 0.1 + 0.1+0.1=0.5
• 在设计（或使用） GC算法时，我们必须确定我们的目标： 一个GC算法只可能针对两个目标之一（即只专注于较大吞吐量或最小暂停时间），或.尝试找到一个二者的折衷。
• 现在标准：在最大吞吐量优先的情况下，降低停顿时间

2 垃圾回收器的发展迭代史

• Serial GC：
  • 1999年jdk1.3.1
  • 第一款GC
• ParNew: 是SerialGC收集器的多线程版本
• Parallel GC和Concurrent Mark Sweep GC
  • jdk1.4.2
  • 2002年2月26日
  • ParallelGC在JDK1.6之后称为HotSpot默认GC
• G1
  • jdk1.7u4
  • 2012年
  • 2017年JDK9中G1变成默认的垃圾收集器，以替代CMS
  • 2018年3月，JDK10中G1垃圾回收器的并行完整垃圾回收，实现并行性改善最坏情况下的延迟
• 2018年9月，JDK11发布。引入Epsilon垃圾回收器，又被称为"No一0p （无操作） "回收器。同时，引入ZGC：可伸缩的低延迟垃圾回收器（Experimental）
• 2019年3月，JDK12发布。 增强G1，自动返回未用堆内存给操作系统。同时，引入Shenandoah GC：低停顿时间的GC （Experimental）
• 2019年9月，JDK13发布。增强ZGC，自动返回未用堆内存给操作系统
• 2020年3月，JDK14发布。删除CMS垃圾回收器。扩展ZGC在macOS和Windows.上的应用

2.1 7款经典的垃圾收集器

• 串行回收器：Serial. Serial Old

• 并行回收器：ParNew. Parallel Scavenge. Parallel Old

• 并发回收器：CMS. G1 7款经典的垃圾收集器与垃圾分代之间的关系

• 新生代收集器： Serial、 ParNeW、Parallel Scavenge；

• 老年代收集器： Serial 0ld、 Parallel 0ld、 CMS；

• 整堆收集器： G1； 垃圾收集器的组合关系

• 其中Serial 0ld作为CMS 出现"Concurrent Mode Failure"失败的后 备预案。

• （红色虚线）由于维护和兼容性测试的成本，在JDK 8时将Serial+CMS、 ParNew+Serial 01d这两个组合声明为废弃（JEP 173） ，并在JDK 9中完全取消了这些组合的支持（JEP214），即：移除。

• （绿色虚线）JDK 14中：弃用Parallel Scavenge和Serial0ld GC组合（JEP366 ）

• （青色虚线）JDK 14中：删除CMS垃圾回收器 （JEP 363）

2.2 查看默认的垃圾收集器

• -xx：+PrintCommandLineFlags： 查看命令行相关参数（包含使用的垃圾收集器）
• 使用命令行指令： jinfo 一flag相关垃圾回收器参数进程ID

/**
 *  -XX:+PrintCommandLineFlags
 *
 *  -XX:+UseSerialGC:表明新生代使用Serial GC ，同时老年代使用Serial Old GC
 *
 *  -XX:+UseParNewGC：标明新生代使用ParNew GC
 *
 *  -XX:+UseParallelGC:表明新生代使用Parallel GC
 *  -XX:+UseParallelOldGC : 表明老年代使用 Parallel Old GC
 *  说明：二者可以相互激活
 *
 *  -XX:+UseConcMarkSweepGC：表明老年代使用CMS GC。同时，年轻代会触发对ParNew 的使用
 */
public class GCUseTest {
    public static void main(String[] args) {
        ArrayList<byte[]> list = new ArrayList<>();

        while(true){
            byte[] arr = new byte[100];
            list.add(arr);
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

• jdk8 使用的是parallel
• jdk9 使用的是G1

3 Serial回收器:串行回收

3.1 概述

• Serial收集器采用复制算法，串行回收和STW机制的方式执行内存回收
• 除了年轻代，还有用于执行老年代的Serial old收集器，同样采取了串行回收，但是用标记压缩算法
• 使用一个CPU或者一条收集线程去完成垃圾收集工作，在进行垃圾收集时，必须暂停其他所有工作线程

3.2 优点

• 简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Seria1收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率
• 只要不频繁发生，使用串行回收器是可以接受的
• 在HotSpot虛拟机中，使用-XX： +UseSerialGC 参数可以指定年轻代和老年代都使用串行收集器。等价于新生代用Serial GC，且老年代用Serial 0ld GC

3.3 总结

• 这种垃圾收集器大家了解，现在已经不用串行的了。而且在限定单核cpu才可以用。现在都不是单核的了
• 对于交互较强的应用而言，这种垃圾收集器是不能接受的

4 ParNew回收器:并行回收

• 如果说Serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是Serial收集器的多线程版本。Par是Paralle1的缩写，New： 只能处理的是新生代
• 除了采用并行回收，其他方面和Serial之间几乎没有任何区别
• ParNew 收集器运行在多CPU的环境下，由于可以充分利用多CPU、 多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量
• 在单个CPU的环境下，ParNew收 集器不比Serial收集器更高效，切换代价
• 因为除Serial外，目前只有ParNew GC能与CMS收集器配合工作
• 在程序中，开发人员可以通过选项"一XX： +UseParNewGC"手动指定使用.ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代
• -XX：ParallelGCThreads 限制线程数量，默认开启和CPU数据相同的线程数

5 Parallel回收器:吞吐量优先

5.1 概述

• Parallel Scavenge收集器同样也采用了复制算法、并行回收和"Stop the World"机制
• 和ParNew收集器不同，Parallel Scavenge收集 器的目标则是达到一个可控制的吞吐量 （Throughput），它也被称为吞吐量优先的垃圾收集器
• 自适应调节策略也是Parallel 与ParNew的一个重要区别
• 适合后台运算不需要太多交互的任务，例如执行批量处理，订单处理，工资支付，科学计算的应用程序
• Parallel old采取标记压缩算法，同样基于并行回收和STW机制

5.2 参数配置

• -XX:+UseParallelGC ： 手动指定年轻代使用此收集器执行内存回收任务
• -XX:+UseParallelOldGC ： 手工指定老年代使用并行回收收集器，分别适用于新生代和老年代，默认jdk8是开启的，与上面这两个参数关联，开启一个，默认开启另一个。
• -XX:ParallelGCThreads ： 设置年轻代并行收集器的线程数，一般与CPU数量相同，如果CPU数量大于8个，则值=3+（5*N/8）
• -XX:MaxGCPauseMillis ： 设置收集器最大停顿时间，单位毫秒。使用需谨慎
• -XX:GCTimeRatio ： 垃圾收集时间占总时间的比例，用于衡量吞吐量大小。默认99，取值范围0-100，也就是垃圾回收时间不超过1%。与上一个参数矛盾，暂停时间越长，Ratio参数就容易超过设定比例
• -XX:+UseAdaptiveSizePolicy : 开启自适应调节策略
  • 在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年 代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点
  • 为了达到堆大小，吞吐量和停顿时间之间的平衡点
  • 在手动调优比较困难的场景下，可以直接用自适应方式，仅指定虚拟机最大堆，目标吞吐量和停顿时间，让虚拟机自己完成调优工作

6 CMS回收器:低延迟

• jdk1.5推出Concurrent Mark Sweep 并发的标记清除，第一次实现了让垃圾收集线程与用户线程同时工作。HotSpot虚拟机中第一款真正意义上的并发收集器
• CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间
• 不幸的是，CMS 作为老年代的收集器，却无法与JDK 1.4.0 中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1. 5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个

6.1 CMS回收器的4个阶段

CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶段，即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段

• 1.初始标记：STW，仅仅只是标记处GC Roots能直接关联的对象，一旦标记完成后就会恢复之前被暂停的所有应用线程，由于直接关联对象比较小，所以这里速度非常快
• 2.并发标记：从GCRoots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长，但是不需要停顿用户线程。可以与垃圾收集线程一起并发运行
• 3.重新标记：为了修正并发标记期间，因用户程序继续运作导致标记产生变动的那一部分对象的标记记录
• 4.并发清除：清理删除标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也可以与用户线程同时并发

6.2 详情

• 初始标记和重新标记阶段仍然需要STW机制
• 由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此CMS收集器不能像其他收集器那样等到老年代几乎填满再进行回收，而是当堆内存使用率达到某一阈值时，便开始进行回收。
• 要是CMS运行期间预留的内存无法满足程序需要，就会出现一次Concurrent Mode Failure失败，这时虚拟机启用备用方案，临时启用Serial old 收集器来重新进行老年代的垃圾收集，这样停顿时间就长了。
• CMS采取标记清除算法，会产生内存碎片，只能够选择空闲列表执行内存分配

CMS收集器的垃圾收集算法采用的是标记一清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块，不可避免地将会产生一些内存碎片。 那么CMS在为新对象分配内存空间时，将无法使用指针碰撞（Bump the Pointer） 技术，而只能够选择空闲列表（Free List） 执行内存分配

有人会觉得既然Mark Sweep会造成内存碎片，那么为什么不把算法换成Mark Compact呢？

答案其实很简答，因为当并发清除的时候，用Compact整理内存的话，原来的用户线程使用的内存还怎么用呢？要保证用户线程能继续执行，前提的它运行的资源不受影响嘛。Mark Compact更适合“Stop the World”这种场景”下使用

6.3 CMS的优点

• 并发收集
• 低延迟

6.4 CMS的缺点

• 会产生内存碎片
• 对CPU资源非常敏感，在并发阶段会占用一部分线程导致应用程序变慢
• 无法处理浮动垃圾，并发标记阶段是与工作线程同时运行，如果并发阶段产生垃圾对象，CMS无法进行标记，导致新产生的垃圾对象没有被及时回收，只能在下一次执行GC时释放空间

6.5 参数设置

• -XX:+UseConcMarkSweepGC ： 手工指定CMS收集器执行内存回收任务，
  • 开启后，自动将-XX:UseParNewGC打开，即ParNew（Young区）+CMS（old区）+Serial GC组合
• -XX:CMSlnitiatingOccupanyFraction ： 设置堆内存使用率的阈值，一旦达到该阈值，则开始进行回收
  • jdk5及之前默认68，即老年代的空间使用率达到68%时会执行一次CMS回收
  • JDK6及以上默认值为92%
  • 如果内存增长缓慢，可以设置一个稍大的值，有效降低CMS的触发频率，减少老年代回收的次数
  • 如果应用程序内存使用率增加很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。
• -XX:+UseCMSCompactAtFullCollection : 用于执行完Full GC后对内存空间进行压缩整理,不过内存压缩无法并发执行，会带来停顿时间更长的问题
• -XX:CMSFullGCsBeforeCompaction : 设置执行多少次FullGC后对内存空间进行压缩整理
• -XX:ParallelCMSThreads ： 设置CMS的线程数量
  • 默认启动的线程数是(ParallelGCThreads+3)/4
  • ParallelGCThreads是年轻代并行收集器的线程数

6.6 小结

• 如果想要最小化使用内存和并行开销，选择Serial GC
• 如果最大化应用程序的吞吐量，选择ParallelGC
• 如果想要最小化的GC的中断或停顿时间，选择CMS GC
• jdk9标记为废弃，UseConcMarkSweepGC来开启CMS收集器的话，用户会收到一个警告信息，提示CMS未来将会被废弃。
• jdk14已经删除了。UseConcMarkSweepGC的话，JVM不会报错，只是给出一个warning信息，但是不会exit，以默认GC方式启动JVM

7 G1回收器:区域化分代式

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

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

• G1是一个并行回收器，它把堆内存分割为很多不相关的区域（Region） （物理上 不连续的）。使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等
• G1 GC有计划地避免在整个Java 堆中进行全区域的垃圾收集。G1跟踪各个Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region
• 由于这种方式的侧重点在于回收垃圾最大量的区间（Region），所以我们给G1一个名字：垃圾优先（Garbage First）
• 在JDK1. 7版本正式启用，移除了Experimental的标识，是JDK 9以后的默认垃圾回收器，取代了CMS回收器以及Parallel + Parallel 0ld组合。被Oracle官方称为“全功能的垃圾收集器”
• 与此同时，CMS已经在JDK 9中被标记为废弃（deprecated） 。在jdk8中还不是默认的垃圾回收器，需要使用一XX： +UseG1GC来启用

7.2 优势

• 并行与并发
  • 并行性： G1在回收期间，可以有多个Gc线程同时工作，有效利用多核计算能力。此时用户线程STW
  • 并发性： G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况
• 分代收集：同时兼顾年轻代与老年代
  • 从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代，年轻代依然有Eden区和Survivor区。但从堆的结构，上看，它不要求整个Eden区、年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。
  • 将堆空间分为若干个区域（Region） ，这些区域中包含了逻辑上的年轻代和老年代。
  • 和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代；
• 空间整合
  • CMS： “标记一清除”算法、内存碎片、若干次Gc后进行一次碎片整理
  • G1将内存划分为一个个的region。 内存的回收是以region作为基本单位的.Region之间是复制算法，但整体上实际可看作是标记一压缩（Mark一Compact）算法，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候，G1的优势更加明显。
• 可预测的停顿时间模型
  • 由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制
  • 能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不能超过N毫秒
  • G1跟踪各个Region里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。保证了G1 收集器在有限的时间内可以获取尽可能高的收集效率

7.3 缺点

• 相较于CMS，G1不具备全方位，压倒性优势。比如用户程序运行中，G1无论是为了垃圾收集产生的内存占用，还是程序运行时的额外执行负载都要比CMS要高
• 经验上来说，小内存应用CMS表现大概率优于G1，在大内存上G1优势发挥更多，平衡点再6-8GB

7.4 参数设置

• -XX:+UseG1GC ： 手动指定使用G1收集器执行内存回收任务
• -XX:G1HeapRegionSize ： 设置每个Region大小，值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆划分出约2048个区域，默认是堆内存的1/2000
• -XX:MaxGCPauseMillis ： 设置期望达到的最大GC停顿时间指标，JVM尽力但不保证，默认200ms
• -XX:ParallelGCThread ： 设置STW工作线程数的值，最多设置8
• -XX:ConcGCThreads ： 设置并发标记的线程数，将N设置为并行垃圾回收线程数（parallelGCThreads）的1/4左右
• -XX:InitiatingHeapOccupancyPercent ： 设置触发并发GC周期的Java堆占用率阈值，超过此值就触发GC，默认是45

7.5 G1回收器的常见操作步骤

1的设计原则就是简化JVM性能调优，开发人员只需要简单的三步即可完成调优：

• 第一步：开启G1垃圾收集器
• 第二步：设置堆的最大内存
• 第三步：设置最大的停顿时间 G1中提供了三种垃圾回收模式： YoungGC、 Mixed GC和Full GC， 在不同的条件下被触发

7.6 适用场景

• 面向服务端应用，针对具有大内存、多处理器的机器
• 最主要的应用是需要低GC延迟，并具有大堆的应用程序提供解决方案
• 如：在堆大小约6GB或更大，可预测的暂停时间可以低于0.5s，G1每次清理一部分region来保证每次GC停顿时间不会过长
• 用来替换掉JDK1.5中的CMS收集器； 在下面的情况时，使用G1可能比CMS好：
  • ①超过50%的Java堆被活动数据占用；
  • ②对象分配频率或年代提升频率变化很大；
  • ③GC停顿时间过长（长于0. 5至1秒）

7.7 分区region

• 使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂，即1MB， 2MB， 4MB， 8MB， 1 6MB， 32MB。可以通过-XX：G1HeapRegionSize设定。所有的Region大小相同，且在JVM生命周期内不会被改变
• 虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region （不需要连续）的集合。通过Region的动态分配方式实现逻辑_上的连续
• 一个region 有可能属于Eden， Survivor 或者0ld/Tenured 内存区域。但是一个region只可能属于一个角色。图中的E表示该region属于Eden内存区域，s表示属于Survivor内存区域，o表示属于0ld内存区域。图中空白的表示未使用的内存空间
• G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。主要用于存储大对象，如果超过1. 5个region，就放到H
• 设置H的原因 ： 对于堆中的大对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放大对象。如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full GC。G1的大多数行为都把H区作为老年代的一部分来看待

7.8 G1回收器垃圾回收过程

• G1 GC的垃圾回收过程主要包括如下三个环节：
  • 年轻代GC （Young GC ）
  • 老年代并发标记过程（ Concurrent Marking）
  • 混合回收（Mixed GC ）
  • （如果需要，单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。）

• 应用程序分配内存，当年轻代的Eden区用尽时开始年轻代回收过程； G1的年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期，G1 GC暂停所有应用程序线程，启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到Survivor区间或者老年区间，也有可能是两个区间都会涉及。
• 当堆内存使用达到一定值（默认45%）时，开始老年代并发标记过程。
• 标记完成马.上开始混合回收过程。对于一个混合回收期，G1 GC从老年区间移动存活对象到空闲区间，这些空闲区间也就成为了老年代的一部分。和年轻代不同，老年代的G1回收器和其他GC不同，G1的老年代回收器不需要整个老年代被回收，一次只需要扫描/回收一小部分老年代的Region就可以了。同时，这个老年代Region是和年轻代一起 被回收的
• 举个例子：一个web服务器，Java进程最大堆内存为4G，每分钟响应1500个请求，每45秒钟会新分配大约2G的内存。G1会每45秒钟进行一次年轻代回收，每31 个小时整个堆的使用率会达到45号，会开始老年代并发标记过程，标记完成后开始四到五次的混合回收

7.9 记忆集与写屏障

• 一个对象被不同区域引用的问题(分代引用问题)
• 一个Region不可能是孤立的，一个Region中的对象可能被其他任意Region中对象引用，判断对象存活时，是否需要扫描整个Java堆才能保证准确？
• 在其他的分代收集器，也存在这样的问题（ 而G1更突出）
• 在其他的分代收集器，也存在这样的问题（ 而G1更突出）
• 这样的话会降低MinorGC的效率；
• 解决方法：
  • 无论G1还是其他分代收集器，JVM都是使用RememberedSet来避免全局扫描
  • 每个Region都有 一个对应的Remembered Set
  • 每次Reference类 型数据写操作时，都会产生一个Write Barrier暂 时中断操作
  • 然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region （其他收集器：检查老年代对象是否引用了新生代对象）
  • 如果不同，通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中
  • 当进行垃圾收集时，在GC根节点的枚举范围加入Remembered Set；就可以保证不进行全局扫描，也不会有遗漏

7.10 G1回收过程详解

7.10.1 年轻代GC

JVM启动时，G1 先准备好Eden区，程序在运行过程中不断创建对象到Eden区，当Eden空间耗尽时，G1会启动一次年轻代垃圾回收过程，年轻代垃圾回收只会回收Eden区和Survivor区，YGC时，首先G1停止应用程序的执行（Stop一The一World），G1创建回收集（Collection Set），回收集是指需要被回收的内存分段的集合，年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段。

• 1、扫描根
  • 根是指static变量指向的对象，正在执行的方法调用链上的局部变量等。根引用连同Rset记录的外部引用作为扫描存活对象的入口
• 2、更新Rset
  • 处理dirty card queue中的card，更新Rset，此阶段完成后，Rset可以准确的反应老年代所在的内存分段中对象的引用
  • dirty card queue 对于应用程序的引用赋值语句object.field=object，JVM会在之前和之后执行特殊的操作以在dirty card queue中入队一个保存了对象引用信息的card。在年轻代回收的时候，G1会对Dirty Card Queue中所有的card进行处理，以更新RSet，保证RSet实时准确的反映引用关系。那为什么不在引用赋值语句处直接更新RSet呢？这是为了性能的需要，RSet的处理需要线程同步，开销会很大，使用队列性能会好很多
• 3、处理Rset
  • 识别被老年代对象指向的Eden中的对象，这些被指向的Eden中的对象被认为是存活的对象
• 4、复制对象
  • 对象树被遍历，Eden区内存段中存活的对象会被复制到Survivor去中空的内存分段，Survivor区内存段中存活的对象如果年龄未达阈值，会加一，达到阈值会被复制到old区中空的内存分段，如果Survivor区空间不够，Eden空间的部分数据会直接晋升到老年代空间
• 5、处理引用
  • 处理强软弱虚，终结器引用，本地方法接口引用等，最终eden空间的数据为空，GC停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片。

7.10.2 并发标记过程

• 1、初始标记阶段：标记从根节点直接可达的对象。这个阶段是STW的，并且会触发一次年轻代GC
• 2、根区域扫描（Root Region Scanning） ： G1 GC扫描Survivor区直接可达的老年代区域对象，并标记被引用的对象。这一过程必须在young GC之前完成
• 3、并发标记（Concurrent Marking）： 在整个堆中进行并发标记（和应用程序并发执行），此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。同时，并发标记过程中，会计算每个区域的对象活性（区域中存活对象的比例）
• 4、再次标记（Remark）： 由 于应用程序持续进行，需要修正上一次的标记结果。是STW的。G1中采用了比CMS更快的初始快照算法：snapshot-at-the-beginning （SATB）
• 5、独占清理（cleanup，STW）：计算各个区域的存活对象和GC回收比例，并进行排序，识别可以混合回收的区域。为下阶段做铺垫。是STW的
• 6、并发清理阶段：识别并清理完全空闲的区域

7.10.3 混合回收

• 当越来越多的对象晋升到老年代old region时，为了避免内存被耗尽，虚拟机会触发一次混合的垃圾收集器，该算法除了回收整个young region，还会回收一部分的old region。也要注意Mixed gc并不是fullgc
• 并发标记结束后，老年代中百分百为垃圾的内存分段被回收了。部分为垃圾的内存分段被计算出来了，默认情况下，这些老年代的内存分段会分8次被回收-XX:G1MixedGCCountTarget设置
• 混合回收的回收集包括八分之一的老年代，Eden区内存分段，Survivor区内存分段
• 由于老年代中内存分段默认分8次回收，G1会优先回收垃圾多的内存分段，并且有一个阈值会决定内存分段是否被回收。-XX:G1MixedGCLiveThresholdPercent，默认为65%。意思是垃圾占比达到65%才会被回收。如果垃圾占比比较低，意味存活对象较高，复制的时候花更多时间。
• 混合回收不一定要进行8次，有一个阈值：-XX:G1HeapWastePercent。默认值是10%，意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存比例低于10%，则不再进行混合回收，因为GC花费更多的时间，但是回收到的内存却很少。

7.10.4 Full GC

• G1初衷就是要避免FULLGC，如果上述方式不能正常工作，G1会停止应用程序的执行。使用单线程的内存回收算法进行垃圾回收，性能非常差。应用程序停顿时间长
• 比如堆太小，当G1复制存活对象的时候没有空的内存分段可用，则会回退到FullGC
• 导致FullGC原因可能有两个：1、回收阶段的时候没有足够的to-space存放晋升的对象 2、并发处理过程完成之前空间耗尽了

小结

• 年轻代大小
  • 避免使用一Xmn或一XX：NewRatio等相关选项显式设置年轻代大小➢固定年轻代的大小会覆盖暂停时间目标
• 暂停时间目标不要太过严苛
  • G1 GC的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间
  • 评估G1 GC的吞吐量时，暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量。

8 垃圾器总结

• Java垃圾收集器的配置对于JVM优化来说是一个很重要的选择，选择合适的垃圾收集器可以让JVM的性能有一个很大的提升。

• 怎么选择垃圾回收器

  • 1.优先调整堆的大小让JVM自适应完成。
  • 2.如果内存小于100M，使用串行收集器
  • 3.如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
  • 4.如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
  • 5.如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用），使用并发收集器

• 官方推荐G1，性能高。现在互联网的项目，基本都是使用G1。

• 最后需要明确一个观点： 1.没有最好的收集器，更没有万能的收集； 2.调优永远是针对特定场景、特定需求，不存在一劳永逸的收集器

11 GC日志分析

• -XX： +PrintGC 输出Gc日志。类似： 一verbose：gc
• -XX： +PrintGCDetails 输出GC的详细日志
• -XX： +PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
• -XX： +PrintGCDateStamps输出GC的时间戳（以日期的形式，如2013一05一04T21 ： 53：59.234+0800 ）
• -XX： +PrintHeapAtGC 在进行GC的前后打印出堆的信息
• -Xloggc：. . /logs/gc. log日志文件的输出路径

11.1 +PrintGC

打开GC日志：一verbose：gc。这个只会显示总的GC堆的变化， 如下：

[GC （Allocation Failure） 80832K一>19298K（227840K），0.0084018 secs]
[GC （Metadata GC Threshold） 109499K一>21465K （228352K），0.0184066 secs]
[Full GC （Metadata GC Threshold） 21 465K一>16716K （201728K），0.0619261 secs ]

分析：

GC、Full GC： GC的类型，GC只在新生代上进行，Full GC包括永生代，新生代， 老年代。
Allocation Failure： GC发生的原因。
80832K一> 19298K：堆在GC前的大小和GC后的大小。
228840k：现在的堆大小。
0.0084018 secs： GC持续的时间。

11.2 +PrintGCDetails

[GC （Allocation Failure） [ PSYoungGen： 70640K一> 10116K（141312K） ] 80541K一>20017K （227328K），0.0172573 secs] [Times： user=0.03 sys=0.00， real=0.02 secs ]
[GC （Metadata GC Threshold） [PSYoungGen：98859K一>8154K（142336K） ] 108760K一>21261K （228352K），
0.0151573 secs] [Times： user=0.00 sys=0.01， real=0.02 secs]
[Full GC （Metadata GC Threshold） [PSYoungGen： 8154K一>0K（142336K） ] [ParOldGen： 13107K一>16809K（62464K） ] 21261K一>16809K （204800K），[Metaspace： 20599K一>20599K （1067008K） ]，0.0639732 secs]
[Times： user=0.14 sys=0.00， real=0.06 secs]

分析：

GC，Full FC：同样是GC的类型
Allocation Failure： GC原因
PSYoungGen：使用了Parallel Scavenge并行垃圾收集器的新生代GC前后大小的变化
ParOldGen：使用了Parallel Old并行垃圾收集器的老年代Gc前后大小的变化
Metaspace： 元数据区GC前后大小的变化，JDK1.8中引入了 元数据区以替代永久代
xxx secs ： 指Gc花费的时间
Times： user： 指的是垃圾收集器花费的所有CPU时间，sys： 花费在等待系统调用或系统事件的时间， real ：GC从开始到结束的时间，包括其他进程占用时间片的实际时间。

11.3 +PrintGCTimeStamps

带上了日期和时间

2019一09一24T22：15：24.518+0800：3.287： [GC（Allocation Failure） [ PSYoungGen： 1361 62K一>5113K（136192K） ] 141425K一>17632K （222208K） ，0.0248249 secs] [Times： user=0.05sys=0.00， real=0.03 secs ]
2019一09一24T22：15：25.559+0800：4.329： [ GC（Metadata GC Threshold）[PSYoungGen：97578K一>10068K（274944K） ] 110096K一>22658K （360960K），0.0094071 secs]
[Times： user=0. 00sys=0.00， real=0. 01 secs]
2019一09一24T22：15：25.569+0800：4.338： [Full GC （Metadata GC Threshold）[ PSYoungGen：10068K一>0K（274944K） ] [ ParoldGen： 12590K一>13564K （56320K） ] 22658K一>13564K （331264K） ，
[Metaspace： 20590K一>20590K（1067008K）]， 0. 0494875 secs]
[Times： user=0.17 sys=0. 02，real=0.05 secs ]     

11.4 补充说明

• "[GC"和"[Full GC"说明了这次垃圾收集的停顿类型，如果有"Full"则说明GC发生了"StopThe World"
• 使用Serial收集器在新生代的名字是De fault New Generation， 因此显示的是" [DefNew"
• 使用ParNew收集器在新生代的名字会变成" 【ParNew"，意思是"Parallel New Generation"
• 使用Parallel Scavenge收 集器在新生代的名字是" 【PSYoungGen"
• 老年代的收集和新生代道理一样，名字也是收集器决定的
• 使用G1收集器的话，会显示为"garbage一 first heap"
• Allocation Failure 表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了
• [PSYoungGen： 5986K一>696K（8704K）] 5986K一> 704K （9216K） 中括号内： GC回收前年轻代大小，回收后大小，（ 年轻代总大小） 括号外： GC回收前年轻代和老年代大小，回收后大小，（ 年轻代和老年代总大小）
• user代表用户态回收耗时，sys 内核态回收耗时， rea实际耗时。由于多核的原因，时间总和可能会超过real时间

Minor GC Full GC

12 垃圾回收器的新发展

GC仍然处于飞速发展之中，目前的默认选项G1 GC在不断的进行改进，很多我们原来认为的缺点，例如串行的Full GC、Card Table扫描的低效等，都已经被大幅改进，例如，JDK 10以后，Fu1l GC已经是并行运行，在很多场景下，其表现还略优于Parallel GC的并行Full GC实现。即使是Serial GC，虽然比较古老，但是简单的设计和实现未必就是过时的，它本身的开销，不管是GC相关数据结构的开销，还是线程的开销，都是非常小的，所以随着云计算的兴起，在Serverless等新的应用场景下，Serial GC找到了新的舞台。比较不幸的是CMS GC，因为其算法的理论缺陷等原因，虽然现在还有非常大的用户群体，但在JDK9中已经被标记为废弃，并在JDK14版本中移除

12.1 JDK11 新特性

• JEP318 : Epsilon: A No一Op Garbage Collector (Epsilon 垃圾回收器,"No一Op (无操作) "回收器) http: / /openidk.java.net/ieps/318
• JEP333: ZGC: A Scalable Low一 Latency ;Garbage Collector (Experimental) ( ZGC:可伸縮的低延退竝坂回收器，处于试验性阶段)

12.2 Open JDK12的Shenandoah GC

• 现在G1回收器已成为默认回收器好几年了。
• 我们还看到了引入了两个新的收集器： ZGC （ JDK11出现）和Shenandoah（Open JDK12）, 主打特点：低停顿时间
• Shenandoah，无疑是众多GC中最孤独的一个。是第一款不由Oracle公司团队领导开发的HotSpot垃圾收集器。不可避免的受到官方的排挤。比如号称OpenJDK和OracleJDK没有区别的Oracle公司仍拒绝在OracleJDK12中支持Shenandoah。
• Shenandoah垃圾回收器最初由RedHat进行的一项垃 圾收集器研究项目PauselessGC的实现，旨在针对JVM上的内存回收实现低停顿的需求。在2014年贡献给OpenJDK
• Red Hat研发Shenandoah团队对外宣称，Shenandoah垃 圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为200MB还是200GB，99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载
• Shenandoah GC的弱项：高运行负担下的吞吐量下降
• Shenandoah GC的强项：低延迟时间

12.3 革命性的ZGC

• ZGC与Shenandoah目标高度相似，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。 *《深入理解Java虚拟机》一书中这样定义ZGC： ZGC收集器是一款基于Region内存布局的，（暂时） 不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记一压缩算法的，以低延迟为首要目标的一款垃圾收集器。
• ZGC的工作过程可以分为4个阶段：并发标记一并发预备重分配一并发重分配一并发重映射等。
• ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的
• JDK14新特性:
  • JEP 364： ZGC应用在macOS上
  • JEP 365： ZGC应用在windows上 JDK14之前，ZGC仅Linux才支持
• 其他垃圾回收器:AliGC AliGC是阿里巴巴JVM团队基于G1算法，面 向大堆（LargeHeap）应用场景。指定场景下的对比：

---

JVM完整目录

1. jvm概述
2.类加载机制
3.运行时数据区[PC寄存器、虚拟机栈、本地方法栈]
4.运行时数据区[堆]
5.运行时数据区[方法区]
6.暂缺
7. 运行时数据区[对象的实例化内存布局与访问定位、直接内存]
8.执行引擎（Execution Engine）
9.字符串常量池
10.垃圾回收[概述、相关算法]
11.垃圾回收[垃圾回收相关概念]
12.垃圾回收[垃圾回收器]
13.常见的OOM
14. JDK命令行工具