jvm-垃圾回收器3（经典垃圾回收器）

jvm-垃圾回收器1（相关算法）

jvm-垃圾回收器2（相关概念）

jvm-垃圾回收器3（经典垃圾回收器）

一、GC分类与性能指标

1.1 概述

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

java不同版本的新特性：
1、语法层面：Lambda表达式、switch、自动装箱、自动拆箱、enum…
2、API层面：Stream API、新的日期时间、Optional、String、集合框架。
3、底层优化：JVM的优化、GC的变化、元空间、静态域、字符串常量池等

1.2 垃圾回收器分类

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

1. 串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作，此时工作线程被暂停，直到垃圾收集工作完成。

• 在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合，串行回收器的性能超过并行和并发回收器，所以，串行收集器默认被应用到客户端的Clent模式下的JVM中。
• 在并发能力比较强的CPU上，并行回收器产生的停顿时间要短于串行回收器。

2. 和串行回收相反，并行收集可以运用多个CPU同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用的独占式，使用了“Stop-The-World”机制。

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

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

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

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

• 按照工作的内存空间分，可以分为年轻代和老年代垃圾回收器。

1.3 GC性能指标

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

1.4 吞吐量 VS 暂停时间

吞吐量、暂停时间、内存占用三者只能同时满足两者。
随着硬件的不断发展内存已经可以容忍。所以主要考虑：吞吐量和暂停时间。
吞吐量优先，意味着在单位时间内，STW的时间最短：0.2 + 0.2 = 0.4，吞吐量高，但是每次垃圾回收时间较长，高延迟。

暂停时间优先，意味着尽可能让单次STW时间最短： 0.1 + 0.1 + 0.1 + 0.1 + 0.1 = 0.5，低延迟，但是单位时间内吞吐量低。

• 高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序在工作。直觉上，吞吐量越高程序运行越快。
• 低延迟较好因为从最终用户的角度来看不管是GC还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型，有时候甚至短暂的200毫秒暂停都可能打断终端用户体验。因此，具有低暂停时间非常重要，特别是对于一个交互式应用程序。
• “高吞吐量”和“低延迟”是竞争关系。如果选择吞吐量优先，那么必然需要降低内存回收的执行效率，这样会导致GC需要更长的暂停时间来执行内存回收。相反的，如果选择低延迟优先，那么为了降低每次执行内存回收时的暂停时间，也只能频繁地执行内存回收，但这又引起了年轻代内存的缩减和导致程序吞吐量下降。

在设计（或使用）GC算法时，我们必须确定我们的目标：一个GC算法只可能针对两个目标之一（即只关注较大吞吐量或者最小暂停时间）或者尝试找到一个二者的折中方案。
现在的标准：在可控的停顿时间下，尽可能提高吞吐量。即在最大吞吐量优先的情况下，降低停顿时间。

二、不同垃圾回收器概述

2.1 垃圾收集器发展史

有了虚拟机，就一定需要收集垃圾的机制，这就是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在JDK1.6之后成为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上的应用。

2.2 七种典型的垃圾收集器

• 串行回收器：Serial、Serial Old
• 并行回收器：ParNew、Parallel Scavenge、Parallel old
• 并发回收器：CMS、G1

关系图：

组合关系：

1. 两个收集器件有连线，表明它们可以搭配使用：
2. 其中Serial Old作为CMS出现“Concurrent Mode Failure”失败后的后备预案。
3. （红色虚线）由于维护和兼容性测试的成本，在JDK8是将Serial + CMS、ParNew+Serial Old 这连个组合声明为废弃（JEP 173），并在JDK9中完全取消了这些组合的支持（JEP214），即：移除。
4. （绿色虚线）JDK 14中：废弃Parllel Scavenge和serial old GC组合（JEP336）
5. （青色虚线）JDK14中：删除CMS垃圾回收器（JEP 363）

为什么要有很多的收集器，一个不够吗？

因为JAVA的使用场景很多，如：移动端，服务器，有单核的小内存的，多核大内存的，注重低延迟的，注重高吞吐量的等场景。没有一种收集器能够同时满足需求，所以就需要针对不同场景，提供不同的垃圾收集器，提高垃圾收集的性能。没有最好的只有最合适的。

2.3 查看默认垃圾收集器

• -XX:+PrintCommandLineFlags:查看命令行相关参数（包含使用的垃圾收集器）
• 使用命令行指令：jps查看进程ID，再通过jinfo -flag 相关垃圾回收参数 进程ID
  

三、Serial回收器：串行回收

• serial收集器是最基本、历史最悠久的垃圾收集器。jdk1.3之前回收新生代唯一选择。
• serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器。
• serial收集器采用复制算法、串行回收和STW机制的方式执行内存回收。
• 除了年轻代外，serial收集器还提供用于执行老年代serial old收集器。serial old收集器同样也采用了串行回收和STW机制，只不过内存回收算法使用的是标记-压缩算法。

1. serial old是运行在client模式下默认的老年代的垃圾回收器。
2. serial old在server模式下主要两个用途：①与新生代Parallel Scavenge配合使用。②作为老年代CMS收集器的后备垃圾收集方案。

• 优势：简单而高效（与其他收集器在单线程情况下比较），对于单核CPU，由于没有线程交互的开销，专注做垃圾收集，垃圾收集效率较高。（运行在client模式下的虚拟机是不错的选项）
• 在用户桌面应用场景中，可用内存一般不大（几十MB至一两百MB），可以在较短时间内完成垃圾收集（几十ms至一百多ms），只要不频繁发生，使用串行回收器是可以接受的。
• 在Hotspot虚拟机中，使用-XX:+UseSerialGC参数可以指定年轻代和老年代都使用串行收集器。

总结：
串行垃圾收集器现在已经很少使用了，只有单核CPU才会使用，对于交互性较强的应用，这种垃圾收集器是不能被接受。javaweb不会采用串行垃圾收集器。

四、ParNew回收器：并行回收

• 如果说serial GC是年轻代中的单线程垃圾收集器，那么ParNew收集器则是Serial收集器的多线程版本。
• parNew收集器除了采用并行回收的方式外，两款垃圾收集器几乎没有区别。parNew在年轻代中同样也是采用了复制算法、“stop-the-world”机制。
• parNew是很多JVM运行在server模式下的新生代的默认垃圾收集器。
  
• 由于parNew收集器是基于并行回收，那么是否可以断定parNew收集器的回收效率在任何场景下会比serial更高效呢？
  ① parNew运行在多CPU环境下，可以更快的完成垃圾收集，提升程序的吞吐量。
  ②在单核CPU的环境下，parNew比serial收集器效率要低。因为serial虽然是串行回收的，但是由于CPU不需要进行频繁的任务切换，可以避免多线程交互过程中产生的额外开销。
• 除了serial外，目前只有parNew GC能与CMS收集器配合工作。
• 在程序中，开发人员可以通过选项“-XX:+UseParNewGC”手动指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代。
• -XX:ParallelGCThreads 限制线程数量，默认开启和CPU数据相同的线程数。

五、Parallel回收器：吞吐量优先

5.1 概述

• Hotspot年轻代除了拥有parNew是基于并行以外，Parallel Scavenge收集器同样也采用了复制算法、并行回收和“STW”机制。
• 那么Parallel收集器的出现是否多此一举？
  ①和parNew不同，parallel Scavenge收集器的目标则是达到一个可控的吞吐量（Throughput），它也被称为吞吐量优先的垃圾回收器。
  ②自适应调节策略也是Parallel Scavenge与parNew一个重要区别。
• 高吞吐量则可以高效地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此，常见在服务器环境中使用。例如，执行批量处理、订单处理，工资支付、科学计算的应用程序。
• parallel收集器在JDK1.6时提供了指向老年代的垃圾收集器的parallel old收集器，用于代替老年代的serial old收集器。
• parallel old收集器采用了标记-压缩算法，但同样也是基于并行回收和STW机制。
• 在程序吞吐量优先的应用场景中，parallel 收集器和parallel old收集器的组合，在server模式下的内存回收性能很不错。
• 在Java8中，默认的垃圾收集器。

5.2 参数配置

• -XX:+UseParallelGC 手动指定年轻代使用parallel并行收集器执行内存回收任务。
• -XX:+UseParallelOldGC 手动指定老年代都使用并行回收收集器。
  ① 分别适用于新生代和老年代。默认jdk8是开启的
  ②上面两个参数，默认开启一个，另一个也会被开启。（相互激活）
• -XX:ParallelGCThreads 设置年轻代并行收集器的线程数。一般最好与CPU数量相等，以避免过多的线程数影响垃圾回收性能。
  ① 在默认情况下，当CPU数量小于8个，parallelGCTreads的值等于CPU数量。
  ② 当CPU数量大于8个，ParallelGCThreads的值等于 3+[5*CPU_Count/8]
• -XX:+MaxGCPauseMillis 设置垃圾收集器最大停顿时间（即：STW的时间）。单位：毫秒。
  ① 为了尽可能把停顿时间控制在MaxGCPauseMills以内，收集器在工作时会调整Java堆大小或者其他一些参数。
  ② 对于用户来讲，停顿时间越短越好。但是在服务器端，我们注重高并发，整体的吞吐量。所以服务器端适合Parallel进行控制。
  ③ 该参数使用需谨慎。
• -XX:GCTimeRatio 垃圾收集器时间占总时间的比例（= 1 / (N + 1)）。用于衡量吞吐量的大小。
  ① 取值范围（0,100）。默认值99，也就是垃圾回收时间不超过1%
  ② 与前一个-XX:+MaxGCPauseMillis参数有一定的矛盾性。暂停时间越长，Radio参数就容易超过设定的比例。
• -XX:+UseAdaptiveSizePolicy 设置Parallel Scavenge收集器具有自适应调节策略。
  ① 在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，已达到在堆大小、吞吐量和停顿时间之间的平衡点。
  ② 在手动调优比较困难的场合，可以直接使用这种自适应的方式，仅指定虚拟机的最大堆，目标的吞吐量（GCTimeRatio）和停顿时间（MaxGCPauseMills），让虚拟机自己完成调优工作。

六、CMS回收器：低延迟

6.1 概述

• 在jdk1.5时期，Hotspot推出了一款在强交互应用中几乎可以认为有划时代意义的垃圾收集器：CMS（Concurrent-Mark-Sweep）收集器，这款收集器是Hotspot虚拟机中第一款真正意义上的并发收集器，它第一次实现了垃圾收集线程与用户线程同时工作。
• CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短就越适合与用户交互的程序，良好的响应速度能够提升用户体验。
  ① 目前很大一部分Java应用中在互联网站或者B/S系统的服务上。这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以提高用户良好体验。
• CMS的垃圾收集算法采用标记-清除算法，并且也会STW。

CMS作为老年代收集器，却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。

6.2 工作原理

CMS整个过程比之前的收集器要复杂，整个过程分为4个主要阶段：

• 初始标记（Initial-Mark）阶段：此阶段，所有的工作线程将全部暂停STW。该阶段主要任务仅仅只是标记出GC Roots能直接关联到的对象。由于直接关联对象较少，所以这里速度非常快。
• 并发标记（Concurrent-Mark）阶段：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
• 重新标记（Remark）阶段：由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那部分对象的标记记录，这个阶段的停顿时间通常会比初始标记稍微长一些，但是远比并发标记阶段短。
• 并发清除（Concurrent-Sweep）阶段：此阶段清除掉标记阶段判断的已经死亡的对象，释放内存。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

CMS采用并发收集（非抢占式），但是初始标记和重新标记还会执行STW机制暂停工作线程，由于初始标记和重新标记时间较短，最耗时的并发标记和并发清除不需要暂停工作线程，CMS实现了低延迟。另外，由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保应用程序有足够的内存可用。因此CMS垃圾回收器不能像其他收集器一样等到老年代几乎被填满后再进行收集，而是当堆内存使用率达到某一阈值时，便开始进行回收，确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启动Serial Old收集器来重新进行老年代垃圾收集，这样停顿时间会很长。

6.3 垃圾碎片问题

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

为什么不用标记-压缩代替标记-清除？

标记-压缩是移动式的，引用对象地址会发生变化，而CMS收集器是并发收集的，用户线程不会中断，如果使用压缩标记导致对象引用地址不一致。要保证用户线程能继续执行，前提是它的资源不受影响。标记压缩更适合STW场景下使用。

6.4 优缺点

• 优点
  ① 并发收集
  ② 低延迟
• 缺点
  ①会产生内存碎片，导致并发清除后，用户线程可用的空间不足。在无法分配大对象的情况下，不得不提前触发Full GC。
  ② CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用一部分线程而导致应用程序变慢，总吞吐量会降低。
  ③ CMS收集器无法处理浮动垃圾。可能出现“Concurrent Mode Failure”失败而导致另一个Full GC的产生。在并发标记阶段如果产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终会导致这些新产生的垃圾对象没有被及时回收，从而只能在下一次执行GC时释放这些之前未被回收的内存空间。

6.5 参数配置

• -XX:+UseConcMarkSweepGC手动指定使用CMS收集器执行内存回收任务。
  ① 开启该参数会自动将-XX:+UseParNewGC打开。即：ParNew（Young区用）+CMS（Old区用）+Serial Old的组合。
• -XX:CMSInitiatingOccupanyFraction 设置内存使用率的阈值，一旦达到该阈值，便开始进行回收。
  ① jdk5及以前的版本默认值为68，即当老年代的空间使用率达到68%时，会执行一次CMS回收。JDK6及以后默认值为92%
  ② 如果内存增长缓慢，则可以设置一个稍大的值，大的阈值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序的性能。反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Full GC的执行次数。
• -XX:+UseCMSCompactAtFullCollection 用于指定在执行完Full GC后堆内存空间进行压缩整理，以避免内存碎片的产生。不同由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长。
• -XX:+CMSFullGCsBeforeCompaction 设置在执行多少次Full GC后堆内存空间进行压缩整理。
• -XX:ParallelCMSThreads 设置CMS的线程数量。
  ① CMS默认启动线程数是（ParallelGCThreads+3）/4，ParallelGCThreads是年轻代并行收集器的线程数。当CPU资源比较紧张时，受到CMS收集器线程的影响，应用程序的性能在垃圾回收阶段可能会非常糟糕。

6.6 JDK后续版本对CMS改变

• JDK9新特性：CMS被标记为Deprecate(JEP291)
  如果对JDK9及以上版本的Hotspot使用参数-XX:-UseConcMarkSweepGC来开启CMS收集器的话，用户会收到一个警告信息，提示CMS未来将会废弃。
• JDK14新特性：删除CMS垃圾回收器（JEP363）
  移除了CMS垃圾回收器，如果在JDK14中使用-XX:-UseConcMarkSweepGC的话，JVM不会报错，只是给出warning信息，但是不会exit。JVM会自动回退以默认GC方式启动JVM
  

七、G1回收器：区域化分代式

7.1 背景

既然已经有前面几个强大的GC，为什么还要发布Carbage First（G1） GC呢？

原因：
①在于应用程序应对的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序的正常进行，而经常造成STW的GC又跟不上实际业务的需求，所以才会不断尝试对GC进行优化。G1垃圾回收器是在JAVA7 update 4之后引入的一个新的垃圾回收器，是当今收集器技术发展的最前沿成果之一。
②与此同时为了适应在不断扩大的内存和不断增加的处理器数量，进一步降低延迟时间，同时兼顾良好的吞吐量。
③官方给G1设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才当起“全功能收集器”的重任与期望。

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

• 因为G1是一个并行回收器，它把堆内存分割为很多不相关的区域（Region）（物理上是不连续的）。使用不同的Region来表示Eden、幸存区0区、幸存区1区、老年代等。
• G1 GC有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。
• 由于这种方式的侧重点在于回收垃圾最大量的区间（Region），所以我们给G1一个名字：垃圾优先（Garbage First）。

发展历史：

• G1是一款面向服务端应用的垃圾收集器，主要针对配置多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征。
• 在JDK1.7版本证书启用，移除了Experimental的标识，是JDK 9 以后的默认垃圾回收器，取代了CMS回收器以及Parallel + Parallel Old组合。被Oracle官方称为“全功能垃圾收集器”。
• 与此同时，CMS已经在JDK9中标记为废弃（deprecated）。在jdk8中还不是默认的垃圾回收器，需要使用-XX:+UseG1GC来启用。

7.2 优缺点

优点：
与其他GC收集器相比，G1使用了权限的分区算法，其特点如下：

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

缺点：

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

7.3 参数设置

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

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

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

• 第一步：开启G1垃圾收集器
• 第二步：设置堆的最大内存
• 第三步：设置最大停顿时间

G1中提供了三种垃圾回收模式：YoungGC、Mixed GC和Full GC，在不同的条件下触发。

7.5 G1回收器的使用场景

• 面向服务端应用，针对具有大内存、多处理器的机器。
• 最主要的应用是需要低GC延迟，并且有大堆的应用程序提供解决方案。
  如：在堆大小约6GB或者更大时，可预测的暂停时间可以低于0.5秒；（G1通过每次GC只清理一部分而不是全部的Region，保证每次GC停顿时间不会过长）。
• 用来替换掉JDK1.5中的CMS收集器
  在下面的情况时，使用G1可能比CMS好
  ① 超过50%的Java堆被活动数据占用。
  ② 对象分配频率或者年代提升频率变化很大。
  ③ GC停顿时间长（长于0.5至1秒）
• Hotspot垃圾收集器里，除了G1以外，其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作，而G1 GC可以采用应用程序线程承担后台运行的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

7.6 Region：化整为零

• 使用G收集器时，它将正java堆划分成约2048个大小相同的独立Region快，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的幂。可以通过-XX:G1HeapRegionSize设定。所有的Region大小相同，且在JVM生命周期内不会改变。
• 虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。通Region的动态分配方式实现逻辑上的连续。
  
• 设置H的原因：
  对于堆中的大对象，默认直接回被分配到老年代，但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，专门存放大对象。如果一个H区装不下一个大对象，那么G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full GC。G1的多少行为都是把H区作为老年代的一部分来看待。
  

7.7 Remembered Set-记忆集

问题：

• 一个对象被不同区域应用的问题
• 一个Region不可能是孤立的，一个Region中的对象可能被其他任意Region中对象引用，判断对象存活时，是否需要扫描整个Java堆才能保证准确？
• 在其他的分代收集器，也存在这个问题（G1更为突出）
• 回收新生代也不得不同时扫描老年代？
• 这样话会降低Minor GC的效率

解决方案：

• 无论G1还是其他分代收集器，JVM都会使用Remered Set来避免全局扫描；
• 每个Region都有一个对应的Remembered Set
• 每个Reference类型数据写操作时，都会产生一个Write Barrier暂时中断操作
• 然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region（其他收集器：检查老年代对象是否引用了新生代对象）
• 如果不同，通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中
• 当进行垃圾收集时，在GC根节点的枚举范围加入Remebered Set；就可以保证不进行全局扫描，也不会有遗漏。

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%，会开始老年代并发标记过程，标记完成后开始四到五次的混合回收。

八、垃圾回收器总结

九、GC日志分析

十、垃圾回收器的新发展