目录

目录

1.GC 简介

1.1. 引言

1.2. 何为 GC

1.2.1. 手动 GC

1.2.2. 自动 GC

引用计数法

标记清除

2.GC入门分析

2.1.碎片整理

1)对象创建时，执行写入操作越来越耗时

2）内存分配错误

2.2. 分代设想

2.3. 对象分配

对象内存分配过程

2.4. GC 模式分析

3.GC 算法基础

3.1. 标记可达对象

3.2. 移除不可达对象

标记-清除（Mark-Sweep）

标记-清除-整理（Mark-Sweep-Compact）

标记-复制 (Mark and Copy)

4.GC 算法实现

4.1. GC 算法实现简介

4.2. GC 收集器应用分析

4.2.1. Serial 收集器应用分析

 4.2.2. Parallel 收集器应用分析

4.2.3. CMS 收集器应用分析

4.2.4. G1 收集器应用分析

1.GC 简介

1.1. 引言

在理解 GC 之前，先回顾一下 JVM 体系结构，如下图所示：

1.2. 何为 GC

1.2.1. 手动 GC

int send_request() {
 size_t n = read_size();
 int *elements = malloc(n * sizeof(int));
 if(read_elements(n, elements) < n) {
 // elements not freed!
 return -1;
 }
 // …
 free(elements)
 return 0;
}

标记清除

2.GC入门分析

2.1.碎片整理

1)对象创建时，执行写入操作越来越耗时

2）内存分配错误

2.2. 分代设想

分代设想将内存拆分为两个可单独清理的区域，允许采用不同的算法来大幅提高 GC 的性能。但这种方法也不是没有问题。例如，在不同分代中的对象可能会互 相引用 , 这样的对象就难以回收。

2.3. 对象分配

JAVA 中堆内存的内存结构如下图所示：

对象内存分配过程

基于此内存架构，对象内存分配过程如下：

1 ）编译器通过逃逸分析（ JDK8 已默认开启），确定对象是在栈上分配还是在堆上分配。

2 ）如果是在堆上分配，则首先检测是否可在 TLAB （ Thread Local Allocation Buffer ）

上直接分配。

3 ）如果 TLAB 上无法直接分配则在 Eden 加锁区进行分配 ( 线程共享区 ) 。

4 ）如果 Eden 区无法存储对象，则执行 Yong GC （ Minor Collection ）。

5 ）如果 Yong GC 之后 Eden 区仍然不足以存储对象，则直接分配在老年代。

说明：在对象创建时可能会触发 Yong GC ，此 GC 过程的简易原理图分析如下 :

其中：

1) 新生代由 Eden 区和两个幸存区构成 ( 假定为 s1,s2), 任意时刻至少有一个 幸存区是空的 (empty) ，用于存放下次 GC 时未被收集的对象。

2)GC 触发时 Eden 区所有 ” 可达对象 ” 会被复制到一个幸存区，假设为 s1，当幸 存区 s1 无法存储这些对象时会直接复制到老年代。

3)GC 再次触发时 Eden 区和 s1 幸存区中的 ” 可达对象 ”会被复制到另一个幸存区 s2 ，同时清空 eden 区和 s1 幸存区 .

4)GC 再次触发时 Eden 区和 s2 幸存区中的 ” 可达对象 ”会被复制到另一个幸存区 s1 ，同时清空 eden 区和 s2 幸存区 . 依次类推。

5) 当多次 GC 过程完成后，幸存区中的对象存活时间达到了一定阀值（可以用参 数 -XX:+MaxTenuringThreshold 来指定上限，默认 15），会被看成是“年 老”的对象然后直接移动到老年代。

2.4. GC 模式分析

垃圾收集事件 (Garbage Collection events) 通常分为 :

1) Minor GC （小型 GC ）：年轻代 GC 事件， ( 新对象 ) 分配频率越高, Minor GC 的频率就越高

2) Major GC ( 大型 GC): 老年代 GC 事件

3) Full GC （完全 GC ） : 整个堆的 GC 事件

说明：一般情况下可以将 Major GC 与 Full GC 看成是同一种 GC 。

3.GC 算法基础

3.1. 标记可达对象

现在的 GC 算法，基本都是要从标记 ” 可达对象 ” 开始(Marking Reachable Objects),这些标记为可达的对象即为存活对象。同时我们可以将查找可达对象 时的起始位置对象，认为是根对象（ Garbage Collection Roots ）。

基于根对象标记可访问或可达对象，对于不可达对象， GC 会认为是垃圾对象。

例如：在下面图示 中的绿色云朵为根对象，蓝色圆圈为可达对象，灰色圆圈为垃圾对象。

首先，GC 遍历(traverses)内存中整体的对象关系图(object graph)确定根对象,那什么样的对象可作为根对象呢？GC 规范中指出根对象可以是：

3.2. 移除不可达对象

移除不可达对象（Removing Unused Objects）时会因 GC 算法的不同而不同， 但是大部分的 GC 操作一般都可大致分为三类：

标记清除(Mark-Sweep)，标记清除整理(Mark-Sweep-Compact)，标记复制(Mark-Copy).

标记-清除（Mark-Sweep）

标记-清除-整理（Mark-Sweep-Compact）

标记-复制 (Mark and Copy)

4.GC 算法实现

4.1. GC 算法实现简介

其中：

1) 年轻代和老年代的串行收集器： （ Serial GC)

2) 年轻代和老年代的并行收集器： (Parallel GC)

3) 年轻代的并行收集器 (Parallel New) + 老年代的并发收集器CMS（Concurrent Mark and Sweep）

4) 年轻代和老年代的 G1 收集器 , 负责回收年轻代和老年代

4.2. GC 收集器应用分析

4.2.1. Serial 收集器应用分析

 4.2.2. Parallel 收集器应用分析

1) -XX:ParallelGCThreads=20：设置并行收集器的线程数，即：同时多少个 线程一起进行垃圾回收。此值最好配置与处理器数目相等。

2) -XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果 无法满足此时间， JVM 会自动调整年轻代大小，以满足此值。

3) -XX:+UseAdaptiveSizePolicy 设置并行收集器自动选择年轻代区大小和 相应的 Survivor 区比例，以达到目标系统规定的最低响应时间或者收集频 率等，此值建议使用并行收集器时，一直打开。

4) -XX:GCTimeRatio=99 ，设置吞吐量大小，默认值就是 99，也就是将垃圾回 收的时间设置成了总时间的 1% 。它的值是一个 0-100 之间的整数。假设 GCTimeRatio 的值为 n ，那么系统将花费不超过 1/(1+n) 的时间用于垃 圾收集。

总之， Parallel GC 是一种并行收集器，可利用多 CPU 优势，执行并行 GC 操 作，吞吐量较高，并可有效降低工作线程暂停时长。但是因为垃圾收集的所有阶 段都不能被打断，所以 Parallel GC 还是有可能导致长时间的应用暂停。所以 Parallel GC 适合于需要高吞吐量而对暂停时间不敏感的场合，比如批处理任 务。

说明：

4.2.3. CMS 收集器应用分析

使 用 CMS 的 参 数 配 置 ：

-XX:+UseConcMarkSweepGC ， 默 认 开 启 - XX:+UseParNewGC其它参数配置：

1) -XX:+ UseCMSCompactAtFullCollection 执行 Full GC 后，进行一次碎 片整理；整理过程是独占的，会引起停顿时间变长

2) -XX:+CMSFullGCsBeforeCompaction 设置进行几次 Full GC 后，进行一次碎片整理 3) -XX:ParallelCMSThreads 设定 CMS 的线程数量（一般情况约等于可用CPU 数量）总之,

CMS 垃圾收集器在减少停顿时间上做了很多给力的工作 , 大量并发执行的工作并不需要暂停应用线程。如果服务器是多核 CPU，并且主要调优目标是降低延迟 , 那么使用 CMS 是个很明智的选择。 CMS 垃圾收集可减少每一次 GC 停  顿的时间 , 这样会直接影响到终端用户对系统的体验 , 用户会认为系统非常灵敏。

但是因为多数时候都有部分 CPU 资源被 GC 消耗 , 所以在 CPU 资源受限的情况下 ,CMS 会比并行 GC 的吞吐量差一些。还有就是老年代内存碎片问题 , 在某些 情况下 GC 会造成不可预测的暂停时间 , 特别是堆内存较大的情况下。

4.2.4. G1 收集器应用分析

G1 在并发阶段估算每个小堆区存活对象的总数，垃圾最多的小堆区会被优先收集，这也是 G1 名称的由来。

G1 以一种和 CMS 相似的方式执行垃圾回收。 G1 在并发标记阶段估算每个小堆区存活对象的总数，垃圾最多的小堆区会被优先收集，这也是 G1 名称的由来。

顾名思义， G1 将其收集和压缩活动集中在堆中可能充满可回收对象（即垃圾）的区域上。 G1 通过用停顿预测模型来满足用户自定义的停顿时间目标，它基于设定的停顿时间来选择要回收的 regions 数量。

G1 基于标记，清理对应的 regions 时 , 会将对象从一个或多个 region 里复制 到另一个 region 里，在这个过程中会伴随着压缩和释放内存。清理过程在多核机器上都采用并行执行，来降低停顿时间，增加吞吐量。因此 G1 在持续的运行中能减少碎片，满足用户自定义停顿时间需求。这种能力是以往的回收器所不具 备的（例如 CMS 回收器不能进行碎片压缩， ParallelOld 只能进行整堆的压 缩，会导致较长的停顿时间）。

再次强调： G1 不是一个实时的收集器，它只是最大可能的来满足设定的停顿时间。 G1 会基于以往的收集数据，来评估用户指定的停顿时间可以回收多少regions ，需要花费的时间，然后确定停顿时间内可以回收多少个 regions 。

G1 收集器特点：

1) 将 java 堆均分成大小相同的多个区域（ region ， 1M-32M ，最多 2000 个，最大支持堆内存 64G ）。 

2) 内存应用具备极大地弹性 ( 一个或多个不连续的区域共同组成 eden、 survivor 或 old 区，但大小不再固定。 )

3) 相对 CMS 有着更加可控的暂停时间 (pause time) 和 更大的吞吐量 (throughput) 以及更少的碎片（标记整理）

4) 支持并行与并发，可充分利用多 CPU ，多核优势，降低延迟，提高响应速度。

G1 场景应用分析:

1) FullGC 发生相对比较频繁或消耗的总时长过长

2) 对象分配率或对象升级至老年代的比例波动较大

3) 较长时间的内存整理停顿

说明：如果你现在用 CMS 或者 ParallelOldGC ，并且你的程序运行很好，没有经历长时间垃圾回收停顿，建议就不用迁移。

G1 算法应用分析：

1) 年轻代标记复制算法

2) 老年代标记清除整理算法。

G1 关键步骤应用分析： （Old Generation）

1) 初始标记 (Initial Mark): 属于 Young GC 范畴，是 stop-the-world 活动。对持有老年代对象引用的 Survivor 区（ Root 区）进行标记。

2) 根区扫描 (Root Region Scan) ：并发执行，扫描那些对 old 区有引用的 Survivor 区，在 yongGC 发生之前该阶段必须完成。

3) 并发标记 (Concurrent Mark)：并发执行，找出整个堆中存活的对象，将空区域标记为 ”X”, 此阶段也可能会被 Young GC 中断。

4) 再次标记 (Remark) ：完全完成对 heap 存活对象的标记。采用 snapshot-at-the-beginning (SATB) 算法完成，比 CMS 用的算法更快。

5) 清理 (cleanup) ：并发执行，统计小堆区中所有存活的对象 , 并对小堆区进行排序 , 优先清理垃圾多的小堆区，释放内存。

6) 复制 / 清理 (copy/clean)：对小堆区未被清理对象对象进行复制，然后再 清理。

G1 实践应用分析：

1) -XX:MaxGCPauseMillis=200 - 设置最大 GC 停顿时间(GC pause time) 指标 (target). 这是一个软性指标 (soft goal), JVM 会尽力去达成这个 目标 . 所以有时候这个目标并不能达成 . 默认值为 200 毫秒 .

2) -XX:InitiatingHeapOccupancyPercent=45 - 启动并发 GC 时的堆内存 占用百分比 . G1 用它来触发并发 GC 周期 , 基于整个堆的使用率 ,而不只是 某一代内存的使用比例。值为 0 则表示“一直执行 GC 循环 )'. 默认值为 45 ( 表示堆使用了 45%).

总之：

G1 是 HotSpot 中最先进的准产品级 (production-ready)垃圾收集器。重要的 是 , HotSpot 工程师的主要精力都放在不断改进 G1 上面 , 在新的 java 版本 中 , 将会带来新的功能和优化。