垃圾回收器

最新推荐文章于 2025-06-19 17:14:52 发布

原创最新推荐文章于 2025-06-19 17:14:52 发布 · 288 阅读

1 ·

CC 4.0 BY-SA版权

返回主博客

GC分类与性能指标

分类

垃圾收集器没有在规范种进行过多的规定，可以由不同的厂商、不同版本的JVM来实现。

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

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

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

按工作内容区间分，可分为年轻代垃圾回收器和老年代垃圾回收器。

补充：如何研究java不同版本新特性？

语法层面：lambda表达式，switch、自动装拆箱、enum、<>。。。。
API层面：Stream API、新的日期时间，Optional，String，集合框架。
底层优化: JVM的优化，GC的变化，元空间、静态域、字符串常量池等等。

性能指标

吞吐量：运行用户代码的时间占总运行时间的比例

总运行时间= 程序运行时间 + GC运行时间。

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

暂停时间：收集垃圾收集时，程序工作线程被暂停的时间。

收集频率：相对应用程序执行，收集操作发生频率。

内存占用：java堆区所占内存大小。

快速：一个对象从诞生到被回收经历的时间。

吞吐量，暂停时间，和内存占用共同构成“不可能三角”。三者总体表现随着技术的进步越来越好。一款优秀的收集器通常通常最多同时满足其中的两项。

这三项种，暂停时间的重要性日益凸显。因为随着硬件的发展，内存占用多，越来越能容忍，硬件性能的提审也有助于降低收集器运行时对应用程序的影响，即提高了吞吐量。而内存的扩大，对延迟带来的负面也越大。

简单来说，主要抓住两点：

吞吐量

暂停时间

举个例子，一对夫妻（双核）生活在一个房子里面，房子大小代表内存大小，房间里面的物品代表对象。如果房间很大，俩夫妻可以使劲造，但是一旦房间房间需要GC了，那么一次打扫卫生的时间就会很长。家里的家具等生活用品可以理解为老年代的对象，每天用的纸巾纸袋纸盒等垃圾理解为eden区对象。记每次每次清除eden 的时间为 TE，对应总次数为 a，每次清除年代的时间为 TO，对应总次数为b

GC的总耗时 = TE * a + TO * b；如果房间够大，可以将b减小，将a 增大。这样GC总耗时减少。GC总耗时减少，夫妻就可以用更多的时间享受生活，吞吐量也就增大。但是我们GC的总耗时，还是和夫妻俩所造对象转为垃圾的速度成正比的。吞吐量和低延迟也是成矛盾的。

一般标准：在最大吞吐量优先的情况下，降低停顿时间。

不同的垃圾回收器概述

https://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf

垃圾收集器历史

1999 JDK1.3.1一起来的时串行方式的serial GC ，它是第一款。ParNew垃圾收集器时Serial收集器的多线程版本。

2002年2月26日，Parallel GC 和和Concurrent Mark Sweep GC 跟随JDK1.4.4一起发布。

Parallel GC/Parallel Old GC 在JDK6之后成为默认GC

2012年，在JDK1.7u4版本，G1可用。

2017年，JDK9 中G1成为默认垃圾收集器，以替代CMS。

2018年3月，JDK10中G1垃圾回收器的并行完成垃圾回收，实现并行性来改善最坏情况下的延迟。

1018年9月，JDK11发布。引入Epsilon垃圾回收器，又被称为“No-Op（无操作）”回收器。同时，引入ZGC；可伸缩的低延迟垃圾回收器（Experimental）。

2019年3月，JDK12发布，增强G1，自动返回未用堆内存给操作系统。同时，引入Shenandoah GC：低停顿时间的GC（Experimental）。

2019年9月，JDK。增强ZGC，自动返回未用堆内存给操作系统。

2020年3月，JDK14发布。删除CMS垃圾回收器。扩展ZGC在macOS和Windows上的应用。

7款经典垃圾收集器

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

7款经典收集器与垃圾分代之间的关系

新生代收集器：Serial、ParNew、Parallel Scavenge

老年代收集器：Serial Old、Parallel Old、CMS

整堆收集器：G1

垃圾收集器的组合关系

我们要针对不同应用场景选择不同的垃圾收集器。

如何查看默认的垃圾收集器

-XX:PrintCommandLineFlags：使用命令行参数（包含使用的垃圾收集器）

使用jinfo -flag 相关垃圾收集器参数进程Id

Serial回收器：串行回收

Serial 收集器时最基本、历史最悠久的垃圾收集器。JDK1.3之前回收新生代唯一选择。

Serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器。

Serial 收集器采用复制算法、串行回收和STW机制的方式执行内存回收。

除了年轻代之外Seiral收集器针对老年代提供了Serial Old 收集器，同样采用串行和STW机制。只不过内存回收算法采用标记-压缩算法。

Serial Old是运行在Client模式下默认的老年代的垃圾收集器。
Serial Old在Server模式下主要两个用途：1、与新生代的Parallel Scavenge配合使用，2、作为老年代CMS收集器的后背垃圾收集方案。

这个收集器是一个单线程的收集器，它的“单线程”的意义并不仅仅寿命它只会单线程使用一个CPU或一条收集线程区完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。

优势：简单而高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集，自然获得高效。

可以用于桌面应用，桌面应用一般可用内存不大，GC时间一般很短。

-XX:+UseSerialGC 参数可以指定年轻代和老年代都使用串行收集器。

现在已经基本不用串行了。而且单核CPU已经很少了。

对于交互较强的应用而言这种垃圾收集器是不能接受的。

ParNew回收器：并行回收

ParNew时Serial收集器的多线程版本。

Par 时Parallel的缩写，new：是指只能处理新生代。

除了采用并行回收的方式执行内存回收之外，其他和Serial没有区别。统一也是采用复制算法、“STW”机制。

新生代回收频繁，使用ParNew可以加快速度。老年代，回收次数少，使用串行方式节省线程切换开销。

JDK9之后ParNew和Serial Old GC 已经不能配合使用了。

JDK14之后，CMS被移除，ParNew已经无可以配合使用的老年代回收器了。

在多核情况下使用parNew肯定是比Serial高效的。

除了Serial外，目前只有parNew GC 能与CMS配合使用。

使用-XX:+UseParNewGC 开启

使用-XX:ParallelGCThreads = 限定线程数量，默认开启和CPU数据相同线程数。

现在parNew已经不太使用了。

Parallel回收器：吞吐量优先

hotSpot的年轻代除了拥有ParNew收集器是基于并行回收的以外，parallel Scavenge收集器也采用复制算法，并行回收，和STW机制。

和ParNew收集器不同，parallel 收集器的目标是达到一个可控制的吞吐量，也被称为吞吐量优先的垃圾收集器。
自适应调节策略也是Parallel 与ParNew的重要区别。

高吞吐量则可以高效的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。因此在常见的服务器环境中使用。例如，那些执行批量处理、订单处理、科学计算的应用程序。

Parallel 收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel Old 收集器，用来代替老年代的Serial Old 收集器。

Parallel Old 采用标记 - 压缩算法，单同样也是基于并行回收和 STW 机制。

在吞吐量优先的应用场景中，Parallel和Parallel Old 的配合使用，在Server模式下可以发挥良好的性能。

在java8中，默认是此垃圾收集器。

参数设置

-XX:+UseParallelGC：手动指定年轻代使用Prallel。也会激活-XX:+UseParallelOldGC

-XX:+UseParallelOldGC ：手动指定老年代使用Parallel Old.。也会激活-XX:+UseParallelGC

-XX:ParallelGCThreads：设置年轻代并行收集器的线程数，一般地，最好和机器的CPU数量相等。

默认情况下，当CPU数量小于8时，ParallelGCThreads的值等于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:MaxGCPauseMills参数有一定矛盾性。暂停时间越长，Ratio参数就容易超过设定的比例。

-XX:+UseAdaptiveSizePolicy 设置Parallel Scavenge 收集器具有自适应调节策略。

在这种模式下，年轻代的大小，Eden和Survivor的比例，晋升老年代对象的年龄等参数会被自动调整，以达到在堆大小，吞吐量和停顿时间之间的平衡带你。

在手动调节比较困难的场合，可以直接使用这种自适应的方式，仅仅指定虚拟机的最大堆，目标的吞吐量（GCTImeRio）和停顿时间（MaxGCPauseMills）让虚拟机自动完成调优工作。

CMS回收器：低延迟

JDK1.5时期，HotSpot推出一款在强交互应用中几乎可以认为有划时代意义的垃圾收集器：（Concurrent-Mark-Swep），这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。

CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短（低延迟）就越适合与用户交互的程序，良好的响应速度能提升用户体验。

目前很大一部分java应用集中在互联网或者B/S的服务器端上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

CMS的垃圾收集算法采用标记-清除算法，并且也会“STW”。

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

在G1出现之前，CMS使用还是非常广泛的，一直到今天，仍然很多系统使用CMS GC

过程

初始标记阶段L在这个阶段，程序中所有线程都会STW，这个阶段仅仅只是标记出GCroot能直接关联到的对象。一旦标记完成之后就会恢复之前的所有应用线程，由于关联对象比较小，所以这里的速度非常快。

并发标记阶段：从GC root的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长，但是不需要停顿用户线程，可以与拦击收集线程并发运行。

重新标记阶段：修正并发标记期间，因用户程序继续运行而导致标记变动的那一部分对象的标记记录。这个阶段比初始标记短，但比并发标记阶段时间短，这短时间也会STW。

并发清除：此阶段清理删除标记判断为已经死亡的对象，释放内存空间，由于不需要移动存活对象，所以也是可以和用户线程并发的。

优缺点

由于最耗时的时间是并发标记和并发清除阶段，这段时间不需要STW，所以整体回收时低停顿的。
尽管CMS采用的是并发回收，但是在其初始标记和再次标记这两个阶段仍然需要执行STW，虽然这个时间很短。
由于在垃圾清除阶段用户线程没有中断，所以在CMS回收过程中，需要保证应用程序有足够内存可用，因此CMS不能像其他收集器一样要等到老年代几乎填满才能进行收集，而是当堆内存达到一定阈值时，便开始进行回收。如果CMS预留的内存的最大空闲区域无法满足下一次内存分配则会出现 “Concurrent Mode Failure”，这时虚拟机启动预备方案，使用Serial Old 收集器进行老年代回收。
因为，CMS需要和用户线程并发，它不可移动内存的地址，所以，CMS收集器采用标记-清除算法，意味它不可避免产生内存碎片，需要维护空闲列表，下一次内存分配也不方便。
CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户停顿，但是会因为占用一部分资源导致应用程序降低，吞吐量降低。
CMS收集器无法处理浮动垃圾。如果在标记过程中出现新的垃圾，CMS是不能标记。

参数

-XX:+UseConcMarkSweepGC 手动指定使用CMS ，开启该参数后，会自动开启-XX:+UseParNewGC。

-XX:CMSlnitiatingOccupynyFraction, 设置堆内存使用率阈值，达到阈值开始GC。jdk5之前默认68，jdk6以后默认92%。如果内存增长缓慢，这个阈值可以设置大一点，如果内存增长很快，可以设置低一点。

-XX:+UseCMSCompactAtFullCollection 指定执行完Full GC后需要对内存空间进行整理

-XX:CMSFullGCsBeforeCompaction 设置在执行多少次Full GC后对内存进行压缩整理。

-XX:ParallelCMSThreads 设置CMS的线程数量。CMS默认启动线程数量是（ParallelGCThreads + 3）/4。ParallelGCThreads是年轻代并行收集器的线程数。当CPU资源比较紧张的时候，导致GC阶段应用程序的性能非常糟糕。

总结

CSM为了和用户线程并发，为了控制这个并发，CMS不得不延长了GC总耗时，比如需要重新标记，比如它需要维护空闲列表，并且对内存是否足够进行预估，还比如它需要提前GC，从而总体上增加GC次数，GC之后还是内存不够时还得换Serial Old进程GC等等。它不得不增加GC总耗时。有人会说，如果我多核不就好了吗？虽然在多核的情况下，用户线程可以进行，但是这个进行阶段，用户线程执行的资源是受限的。比我们我们机器8个核，我们用4个核进行GC，那么用户线程就只能有4个核工作。在高并发的情况下，4个核的运行速度要比8核运行要慢一倍还多。好比夫妻俩（双核）每次收拾家务只让老婆收拾，老公享受人生，但是这个过程其实是占用了老婆的享受人生的时间。还不如夫妻俩同时收拾（使用parallel 控制其合理参数），然后一起享受生活。由于CMS的弊端和其并发的鸡肋性，jdk14已经将其移除。

G1回收器区域化分代式

业务越来越庞大，复杂，我们机器的内存不断扩大，处理器不断增加，如果内存太大，虽然我们GC频率降低，但是一次GC时间便会加长。因此，java7 update 4之后引入此款垃圾收集器，是当今收集器发展的最前沿成果之一。应对不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间和兼顾良好的吞吐量。

官方目标是在可控延迟下尽可能高的吞吐量，承担起“全功能收集器”的重任。

为什么叫Garbage First？

G1是一块并行回收器，它将堆内存分割为很多不相关的Region。使用不同的Region来表示Eden、Survivor 0,Survivor1 和老年代。
G1 GC有计划地避免在整个堆中进行全区域地垃圾收集。G1 跟踪各个Region里面垃圾堆积地价值大小（回收所获得空间大小以及回收所需要地时间地经验值），在后台维护一个优先列表，每次根据允许地收集时间，优先回收价值最大地Region。
由于这种方式地侧重点在于垃圾回收最大地区间，所以给它取名 “垃圾优先”。

它一款面向服务端应用地垃圾收集器，主要针对配合多核CPU地大容量内存地机器。极高概率满足GC停顿时间地同时，兼顾高吞吐量。

jdk1.7时,移除experimental标识，jdk9之后成为默认收集器。取代CMS回收器，以及parallel + Parallel的组合。CMS在JDK9标记为deprecated，在jdk14彻底移除。在jdk8中需要用-XX:UseG1GC来开启。

与其他GC收集器相比，G1使用了全新的分区算法，其特点如下

并行与并发

并行性：G1在回收期间，可以多个GC线程同时工作。
并发性：G1拥有与应用程序交替执行的能力，部分工作是与用户线程并发进行的，不会咋整个回收阶段完全阻塞应用程序。

分代收集

从分代上看，G1依然属于分代型垃圾收集器，它会区分年轻代和老年代，年轻代依然有eden和survivor区。但从堆的结构上看，它不要求整个eden区，年轻代或者老年代都是连续的，也不再坚持固定大小和固定数量。
将堆空间分为若干个region，这些区域逻辑上分为eden，survivor，和老年代。
和之前各类回收器不同，它同时兼顾年轻代和老年代。

空间整合

CMS使用“标记-清除”算法，内存碎片若干次GC进行一次碎片整理。
G1将内存划分为一个个region。内存的回收是以region作为基本单位的。region直接采用复制算法，但整体上实际可以看做是"标记-压缩"算法，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当堆非常大的时候，G1的优势更加明显。

可预测的停顿时间模型 （软实时 soft real-time），这是G1相对于CMS的另一个大优势，G1除了追求低停顿外，还可以建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不超过N毫秒。

由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收范围，因此对于全局停顿情况的发生也能得到较好的控制。
G1跟踪各个Resion里面垃圾堆积的价值大小（回收获得空间大小以及回收所需要时间的经验值）在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Resion。保证G1收集器在有限的时间内可以获取尽可能高的收集效率
像比于CMS GC，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多。

比较CMS

相比CMS，G1还具备全方位、压倒性优势。比如在用户程序运行过程，G1无论是为了垃圾收集产生内存占用（Footprint）还是程序运行时的额外执行负载都要比CMS要高。

从经验上来说，在小内存应用上CMS的表现大概率会优先于G1，G1在大内存应用上发挥其优势。平衡点在6-8G之间。

G1的参数设置

-XX:+UseG1GC 手动指定使用G1
-XX:G1HeapResionSize 设置每个Region的大小。值是2的整次幂，外围是1MB到32MB之间，目标是根据最小的java堆大小分化出2048个区域。默认是堆内存的1/2000
-XX:MaxGCPauseMills 设置期望达到最大GC停顿时间指标，JVM会尽力实现。默认200ms。
-XX:ParallelGCThread 设置STW工作线程数的值。最多设置为8。
-XX:ConcGCThreads 设置并发标记的线程数。将n设置为并行垃圾回收线程数（ParallelGCThreads）的1/4左右。
-XX:InitialtingHeapOccupyPercent 设置触发GC周期的java堆占用率的阈值。超过此值就要开始GC了。默认45

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

第一步：开启G1垃圾收集器

第二部：设置堆的最大内存

第三步：设置最大的停顿时间

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

G1回收器的适用场景

面向服务器端，针对具有大内存、多处理器的机器。（在普通大小的堆里表现并不惊喜）

最主要的应用是需要低GC延迟，并且具有大堆的应用程序提供解决方案。

在下面情况使用G1可能比CMS好

使用50%的java堆被活动数据占用
对象分配频率或年代提升频率变化很大
内存太大导致GC停顿时间过长

HotSpot垃圾收集器里，除了G1外，其他垃圾收集器使用内置的JVM线程执行GC多线程操作，而G1可以采用应用线程承担后台运行的GC工作，即当JVM的GC线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。。

分区Region化整为零

内存大的场景下，以往的分代算法已经满足不了需求了，G1跳出这个限制，提出region概念。

将整个java堆划为约为2048个大小相同的Region块，region的大小根据堆的实际大小而定，为2的整次幂，大小一旦指定，在JVM运行期间不可改变。新生代和老年代不在物理隔离了，不再连续了，并且这些分代角色都是可以角色变化的，比如某个region之前是eden，后面也有可能变成Old。G1收集器还增加了一种新的内存区域叫做Humongous内存区域，如图中的H块，它用于存储大对象，如果超过1.5个region就放到H。

设置H的原因

对于堆中的大对象，默认直接会被分配到老年代，如果他是一个短期存在的大对象，就会对垃圾收集器造成负面影响，为了解决这个问题，G1划分了一个连续的humongous区，它用来专门存放大对象。如果H区装不下一个大对象那么G1就会寻找连续的H区来存储，为了能找到连续的H区，有时候不得不启动fullGC。G1的大多数行为都把H区作为老年代的一部分来看。

G1回收过程

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

当eden区用尽时开始年代代回收过程：G1的年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期间，G1 暂停所有应用程序线程，启动多线程执行老年代回收。然后从年轻代区域移动存活对象到Survivor区或者老年区，也有可能两个区间都会涉及。

当堆内存是用达到一定值（默认45%）时，开始老年代并发标记过程。

标记完成马上开始混合回收过程。对于一个混合回收期，G1从老年代移动存活对象到空闲区间，这些空闲区间也就成为老年代的一部分，和年轻代不同，老年代的G1回收器和其他GC不同，G1老年代不需要整个老年代回收，一次只需要扫描/回收一部分老年代的Region就可以了。同时这个老年代是和年轻代一起被回收的。

举例：一个web服务器，java进程最大堆内存为4G，每分钟响应1500个请求，每45秒种会重新分配大约2G的内存。G1会每45秒种进行一次年轻代回收，每31小时整个堆的是用率会达到45%，会开始老年代并发标记过程，标记完成后开始4到5次的混合回收。

Remembered Set

一个对象被不同区域引用的问题。

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

解决方法

无论时G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描。

每个Region都有一个对应的Remembered Set；

每次Refer类型数据写操作时，都会产生一个Write Sarrier暂时中断操作；

然后检查将要写入的引用对象是否和该Reference类型数据在不同的Region

如果不同，通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中

当进行垃圾收集时，在GC根本节点的枚举范围加入Remembered Set; 就可以保证不进行全局扫描，也不会有遗漏。

G1回收过程1: 年轻代GC：
第一阶段，扫描根。
根是指static变量指向的对象，正在执行的方法调用链条上的局部变量等。根引用连同RSet记录的外部引用作为扫描存活对象的入口。
第二阶段，更新RSet。
处理dirtycardqueue中的card，更新RSet。此阶段完成后，RSet可以准确的反映老年代对所在的内存分段中对象的引用。
第三阶段，处理RSet。
识别被老年代对象指向的Eden中的对象，这些被指向的Eden中的对象被认为是存活的对象。
第四阶段，复制对象。
此阶段，对象树被遍历，Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段，Survivor区内存段中存活的对象如果年龄未达阈值，年龄会加1，达到阀值会被会被复制到Old区中空的内存分段。如果Survivor空间不够，Eden空间的部分数据会直接晋升到老年代空间。
第五阶段，处理引用。
JLESoft， Weak， Phantom，Final， JNI Weak等引用。最终Eden空间的数据为空，GC停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片。

G1回收过程2: 并发标记过程

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

G1回收过程3：混合回收

当越来越多的对象晋升到老年代oldregion时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即MixedGC，该算法并不是一个oldGC，除了回收整个YoungRegion，还会回收一部分的OldRegion。这里需要注意：是一部分老年代，而不是全部老年代。可以选择哪些old
Region进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是MixedGC并不是FullGC。

并发标记结束以后，老年代中百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算了出来。默认情况下，这些老年代的内存分段会分8次(可以通过-XX：G1MixedGCCountTarget设置)被回收。
混合回收的回收集(CollectionSet)包括八分之一的老年代内存分段，Eden区内存分段，Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回收集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。
由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的，越会被先回收。并且有一个阈值会决定内存分段是否被回收，XX：G1MixedGCLiveThresholdPercent，默认65%才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间。
混合回收并不一定要进行8次。有一个阈值-XX：G1HeapWastePercent，默认值为10%，意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于10%，则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少。

G1可选过程4: Full GC

G1的初衷就是要避免FullGC的出现。但是如果上述方式不能正常工作，G1会停止应用程序的执行(Stop-The-World)，使用单线程的内存回收算法进行垃圾回收，性能会非常差，应用程序停顿时间会很长。要避免FullGC的发生，一旦发生需要进行调整。什么时候会发生FullGC呢?比如堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用，则会回退到fullgc，这种情况可以通过增大内存解决。导致G1FullGC的原因可能有两个：|1.Evacuation的时候没有足够的to-space来存放晋升的对象；2.并发处理过程完成之前空间耗尽。.....O....

补充

从Oracle官方透露出来的信息可获知，回收阶段(Evacuation)其实本也有想过设计成与用户程序一起并发执行，但这s件事情做起来比较复杂，考虑到G1只是回收一部分Region，停顿时间是用户可控制的，所以并不迫切去实现，而选择把这个特性放到了G1之后出现的低延迟垃圾收集器(即ZGC)中。另外，还考虑到G1不是仅仅面向低延迟，停顿用户线程能够最大幅度提高垃圾收集效率，为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。

优化建议

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

垃圾回收器总结

Java垃圾收集器的配置对于JVM优化来说是一个很重要的选择，选择合适的垃圾收集器可以让JVM的性能有一个很大的提升。
怎么选择垃圾收集器?
1.优先调整堆的大小让JVM自适应完成。
2.如果内存小于100M，使用串行收集器
3.如果是单核、单机程序，并且没有停顿时间的要求，串串行收集器
4.如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
5.如果是多CPU、追求低停顿时间，需快速响应(比如延迟不能超过1秒，如互联网应用)，使用并发收集器

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