一篇文章搞懂G1收集器

Posted 2023-04-11

参考技术A Garbage First(简称G1)收集器是垃圾收集器技术发展史上里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。
作为CMS收集器的替代者和继承人，设计者们希望做出一款能够建立起“停顿时间模型”的收集器，停顿时间模型的意思是能够支持指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间大概率不超过N秒这样的目标。

G1的里程碑意义来源于其面向局部收集的设计思路和基于Region的内存布局形式，这也是G1实现其停顿时间模型的底气。在G1收集器出现之前的所有其他收集器，包括被它所替代的CMS，垃圾收集的目标范围都是整个新生代（Minor GC）或整个老年代（Major GC），亦或者是整个Java堆（Full GC）。而G1实现了可以面向堆内存的任何部分来组成回收集。衡量标准不再是分代，而是回收的实际收益，这就是Mixed GC模式。

G1基于Region的堆内存布局是它实现Mixed GC的关键。我们不能说G1摈弃了分代理论，相反，G1依然是依据分代理论设计的，但其堆内存布局与其他收集器有非常明显的差异，它不再坚持固定大小以及固定数量的分代区域划分，而是把堆分成多个大小相等的独立区域，称为Region，而每个Region都可能是新生代或老年代。这样无论是针对哪种对象，都可以有比较好的收集效果。

从上图中我们可以看见，Region中还有一种Humongous区域，它专门用来存储大对象。G1认为一个对象的大小超过了一个Region的一半，那就可以称为大对象。如果对象大小超过一个Region，就存储在连续的多个Region当中。另外值得注意的是，G1的大部分行为都把Humongous Region作为老年代的一部分来看待。

G1之所以能够建立起可预测的停顿时间模型，是因为它将Region作为单次回收的最小单元。G1收集器会跟踪每个Region中垃圾总的“价值”大小，即回收所获得的空间大小和回收所需时间的经验值，然后在后台维护一个优先级列表。并可以根据用户的设定回收价值收益最大的Region。这也是“Garbage First”其名的由来。

G1收集器作为一款跨时代的收集器，它从发表论文到商用经历了超过十年的研发，其中解决了无数的问题，以下是三个典型且重要的问题向读者说明。

和其他收集器解决跨代问题的方法一样，G1使用记忆集从而避免全堆作为GC Roots扫描。但不同的是G1的每个Region都维护属于自己的记忆集，它们会记录下别的Region指向自己的指针，并标记这些指针分别在哪些卡页的范围内。G1的记忆集在存储结构的本质上是哈希表（key是别的Region的起始地址，Value是卡表索引号的集合）。
由于Region的数量较多，而每个Region都有自己的记忆集，所以G1收集器要花费更大的内存来维持工作，这个数通常是Java堆的10%~20%。

首先，用户线程改变对象引用关系时，必须保证不打破原本的对象图结构，导致标记结果出现错误。CMS对这个问题采取了增量更新的算法进行解决，而G1选择了原始快照(SATB)的方法进行解决。
其次，回收过程中会有新对象需要进行内存分配。G1为每个Region设置了两个名为TAMS的指针，把Region的一部分空间用于并发回收过程中的新对象分配。新对象的地址必须在这两个指针之上。这部分空间被收集器视为默认存货， 不纳入回收范围。

G1收集器的停顿预测模型是以衰减均值作为理论基础来实现的。在垃圾收集过程中，G1收集器会记录每个Region的回收时间、记忆集中的脏卡数量等各个步骤的成本，并按照一定的统计信息和统计算法得出“衰减平均值”。衰减平均值更准确地代表了最近的平均状态，Region的统计状态越新就越能决定回收的价值。
根据这些信息，收集器可以决定应当找出哪些Region进入回收集，最终在不超过期望时间的前提下获得最高收益。

标记一下GC Roots能直接关联到的对象。并且修改TAMS的值，让并发标记阶段分配对象有据可依。这个阶段需要停顿线程，但耗时很短，并且在Minor GC时同步完成。

从GC Root中开始对堆中对象进行可达性分析，扫描对象图，找出要回收的对象，这阶段耗时长但是可以和用户程序并发执行。当对象图扫描完成后，还要重新处理SATB记录下的在并发时有引用变动的对象。

对用户线程做一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那些少量的SATB记录。

负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，制定具体的回收计划。可以自由地选择多个Region作为回收集，把其中存活的对象复制到空的Region中，再清理掉整个回收集。由于涉及存活对象的移动，所以必须暂停用户线程。

总之，G1收集器的设计目标是在延迟可控的前提下获得尽可能高的吞吐量。

作为两款关注停顿时间的收集器，G1常被作为CMS收集器的比较对象。在今天，G1已经几乎完全取代了CMS的地位，但这并不意味着CMS在G1面前不值一提。
先说明一个事实：在小内存上CMS的表现可能会优于G1，而大内存上G1毫无疑问会占据优势。这个堆内存大小的平衡点通常在6~8GB左右。

指定最大停顿时间、分Region的内存布局、按收益确定最终回收集，这些都是G1的新设计给它带来的相对于CMS的优势。

CMS集于标记-清除算法进行收集，而G1从整体看集于标记-整理算法进行收集，局部看基于标记-复制算法进行收集。显然，G1的两种解读方法都意味着它不会产生任何内存碎片。这样的特性有利于程序长久地平稳运行。

我们前文中提到，G1收集器为每一个Region都提供了卡表作为记忆集，显然这意味着G1相比CMS需要消耗更大量的内存来完成其本职工作。相比之下CMS的卡表仅有一份且实现简单。

CMS使用写后屏障来更新和维护卡表。G1除了使用写后屏障，为了实现快照搜索算法，它还得使用写前屏障来跟踪并发时的指针变化情况。这也引出了原始快照和增量更新两种方法的比较：原始快照能够减少并发标记和重新标记阶段的损耗，避免在标记阶段停顿时间过长，但它同时也会产生由于跟踪引用变化带来的额外负担。
由于G1写屏障的复杂操作要比CMS消耗更多的运算资源，CMS的写屏障实现是直接的同步操作，而G1必须把它实现为类似消息队列的架构，即把写前屏障和写后屏障要做的事都放到队列里，然后异步处理。

一篇文章带你搞懂 Java 注解的原理

文章目录

• • 一、注解的本质
  • 二、元注解
  • 三、Java 内置的三大注解
  • 四、注解与反射
  • 五、总结

一、注解的本质

注解的本质就是一个继承了 Annotation 接口的接口

例如：
JDK 内置注解的定义：

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}

这是注解 @Override 的定义，其实它本质上就是：

public interface Override extends Annotation{
}

一个注解准确意义上来说，只不过是一种特殊的注释而已，如果没有解析它的代码，它可能连注释都不如。

而解析一个类或者方法的注解往往有两种形式，一种是编译期直接的扫描，一种是运行期反射。

编译器的扫描指的是编译器在对 java 代码编译字节码的过程中会检测到某个类或者方法被一些注解修饰，这时它就会对于这些注解进行某些处理

典型的就是注解 @Override，一旦编译器检测到某个方法被修饰了 @Override 注解，编译器就会检查当前方法的方法签名是否真正重写了父类的某个方法，也就是比较父类中是否具有一个同样的方法签名。

这一种情况只适用于那些编译器已经熟知的注解类，比如 JDK 内置的几个注解，
而你自定义的注解，编译器是不知道你这个注解的作用的，当然也不知道该如何处理，往往只是会根据该注解的作用范围来选择是否编译进字节码文件，仅此而已

二、元注解

元注解是用于修饰注解的注解，通常用在注解的定义上，例如：

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}

这是我们 @Override 注解的定义，你可以看到其中的 @Target，@Retention 两个注解就是我们所谓的元注解，元注解一般用于指定某个注解生命周期以及作用目标等信息。

JAVA 中有以下几个元注解：

• @Target：注解的作用目标
• @Retention：注解的生命周期
• @Documented：注解是否应当被包含在 JavaDoc 文档中
• @Inherited：是否允许子类继承该注解

其中，@Target 用于指明被修饰的注解最终可以作用的目标是谁，也就是指明，你的注解到底是用来修饰方法的？修饰类的？还是用来修饰字段属性的。

我们可以通过以下的方式来为这个 value 传值：

@Target(value = {ElementType.FIELD})

被这个 @Target 注解修饰的注解将只能作用在成员字段上，不能用于修饰方法或者类。

其中，ElementType 是一个枚举类型，有以下一些值：

ElementType.TYPE：允许被修饰的注解作用在类、接口和枚举上
ElementType.FIELD：允许作用在属性字段上
ElementType.METHOD：允许作用在方法上
ElementType.PARAMETER：允许作用在方法参数上
ElementType.CONSTRUCTOR：允许作用在构造器上
ElementType.LOCAL_VARIABLE：允许作用在本地局部变量上
ElementType.ANNOTATION_TYPE：允许作用在注解上
ElementType.PACKAGE：允许作用在包上

@Retention 用于指明当前注解的生命周期，它的基本定义如下：

同样的，它也有一个 value 属性：

@Retention(value = RetentionPolicy.RUNTIME

这里的 RetentionPolicy 依然是一个枚举类型，它有以下几个枚举值可取：

RetentionPolicy.SOURCE：当前注解编译期可见，不会写入 class 文件
RetentionPolicy.CLASS：类加载阶段丢弃，会写入 class 文件
RetentionPolicy.RUNTIME：永久保存，可以反射获取

@Retention 注解指定了被修饰的注解的生命周期，一种是只能在编译期可见，编译后会被丢弃，一种会被编译器编译进 class 文件中，无论是类或是方法，乃至字段，他们都是有属性表的，而 JAVA 虚拟机也定义了几种注解属性表用于存储注解信息，但是这种可见性不能带到方法区，类加载时会予以丢弃，最后一种则是永久存在的可见性。

剩下两种类型的注解我们日常用的不多，也比较简单，这里不再详细的进行介绍了，你只需要知道他们各自的作用即可。@Documented 注解修饰的注解，当我们执行 JavaDoc 文档打包时会被保存进 doc 文档，反之将在打包时丢弃。@Inherited 注解修饰的注解是具有可继承性的，也就说我们的注解修饰了一个类，而该类的子类将自动继承父类的该注解。

三、Java 内置的三大注解

除了上述四种元注解外，JDK 还为我们预定义了另外三种注解，它们是：

@Override
@Deprecated
@SuppressWarnings

@Override 注解想必是大家很熟悉的了，它的定义如下：

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}

它没有任何的属性，所以并不能存储任何其他信息。它只能作用于方法之上，编译结束后将被丢弃。

所以你看，它就是一种典型的『标记式注解』，仅被编译器可知，编译器在对 java 文件进行编译成字节码的过程中，一旦检测到某个方法上被修饰了该注解，就会去匹对父类中是否具有一个同样方法签名的函数，如果不是，自然不能通过编译。

@Deprecated 的基本定义如下：

依然是一种『标记式注解』，永久存在，可以修饰所有的类型，作用是，标记当前的类或者方法或者字段等已经不再被推荐使用了，可能下一次的 JDK 版本就会删除。

当然，编译器并不会强制要求你做什么，只是告诉你 JDK 已经不再推荐使用当前的方法或者类了，建议你使用某个替代者。

@SuppressWarnings 主要用来压制 java 的警告，它的基本定义如下：

它有一个 value 属性需要你主动的传值，这个 value 代表一个什么意思呢，这个 value 代表的就是需要被压制的警告类型。例如：

public static void main(String[] args) {
    Date date = new Date(2018, 7, 11);
}

这么一段代码，程序启动时编译器会报一个警告。

Warning:(8, 21) java: java.util.Date 中的 Date(int,int,int) 已过时

而如果我们不希望程序启动时，编译器检查代码中过时的方法，就可以使用 @SuppressWarnings 注解并给它的 value 属性传入一个参数值来压制编译器的检查。

@SuppressWarning(value = "deprecated")
public static void main(String[] args) {
    Date date = new Date(2018, 7, 11);
}

这样你就会发现，编译器不再检查 main 方法下是否有过时的方法调用，也就压制了编译器对于这种警告的检查。

当然，JAVA 中还有很多的警告类型，他们都会对应一个字符串，通过设置 value 属性的值即可压制对于这一类警告类型的检查。

自定义注解的相关内容就不再赘述了，比较简单，通过类似以下的语法即可自定义一个注解。

public @interface InnotationName{
}

当然，自定义注解的时候也可以选择性的使用元注解进行修饰，这样你可以更加具体的指定你的注解的生命周期、作用范围等信息。

四、注解与反射

上述内容我们介绍了注解使用上的细节，也简单提到，「注解的本质就是一个继承了 Annotation 接口的接口」，现在我们就来从虚拟机的层面看看，注解的本质到底是什么。

首先，我们自定义一个注解类型：

这里我们指定了 Hello 这个注解只能修饰字段和方法，并且该注解永久存活，以便我们反射获取。

之前我们说过，虚拟机规范定义了一系列和注解相关的属性表，也就是说，无论是字段、方法或是类本身，如果被注解修饰了，就可以被写进字节码文件。属性表有以下几种：

RuntimeVisibleAnnotations：运行时可见的注解
RuntimeInVisibleAnnotations：运行时不可见的注解
RuntimeVisibleParameterAnnotations：运行时可见的方法参数注解
RuntimeInVisibleParameterAnnotations：运行时不可见的方法参数注解
AnnotationDefault：注解类元素的默认值

给大家看虚拟机的这几个注解相关的属性表的目的在于，让大家从整体上构建一个基本的印象，注解在字节码文件中是如何存储的。

所以，对于一个类或者接口来说，Class 类中提供了以下一些方法用于反射注解。

getAnnotation：返回指定的注解
isAnnotationPresent：判定当前元素是否被指定注解修饰
getAnnotations：返回所有的注解
getDeclaredAnnotation：返回本元素的指定注解
getDeclaredAnnotations：返回本元素的所有注解，不包含父类继承而来的

方法、字段中相关反射注解的方法基本是类似的，这里不再赘述，我们下面看一个完整的例子。

首先，设置一个虚拟机启动参数，用于捕获 JDK 动态代理类。

-Dsun.misc.ProxyGenerator.saveGeneratedFiles=true

然后 main 函数。

我们说过，注解本质上是继承了 Annotation 接口的接口，而当你通过反射，也就是我们这里的 getAnnotation 方法去获取一个注解类实例的时候，其实 JDK 是通过动态代理机制生成一个实现我们注解（接口）的代理类。

我们运行程序后，会看到输出目录里有这么一个代理类，反编译之后是这样的：

代理类实现接口 Hello 并重写其所有方法，包括 value 方法以及接口 Hello 从 Annotation 接口继承而来的方法。

而这个关键的 InvocationHandler 实例是谁？

AnnotationInvocationHandler 是 JAVA 中专门用于处理注解的 Handler， 这个类的设计也非常有意思。

这里有一个 memberValues，它是一个 Map 键值对，键是我们注解属性名称，值就是该属性当初被赋上的值。

而这个 invoke 方法就很有意思了，大家注意看，我们的代理类代理了 Hello 接口中所有的方法，所以对于代理类中任何方法的调用都会被转到这里来

var2 指向被调用的方法实例，而这里首先用变量 var4 获取该方法的简明名称，接着 switch 结构判断当前的调用方法是谁，如果是 Annotation 中的四大方法，将 var7 赋上特定的值。

如果当前调用的方法是 toString，equals，hashCode，annotationType 的话，AnnotationInvocationHandler 实例中已经预定义好了这些方法的实现，直接调用即可。

那么假如 var7 没有匹配上这四种方法，说明当前的方法调用的是自定义注解字节声明的方法，例如我们 Hello 注解的 value 方法。这种情况下，将从我们的注解 map 中获取这个注解属性对应的值。

五、总结

首先，我们通过键值对的形式可以为注解属性赋值，像这样：@Hello（value = "hello"）。

接着，你用注解修饰某个元素，编译器将在编译期扫描每个类或者方法上的注解，会做一个基本的检查，你的这个注解是否允许作用在当前位置，最后会将注解信息写入元素的属性表。

然后，当你进行反射的时候，虚拟机将所有生命周期在 RUNTIME 的注解取出来放到一个 map 中，并创建一个 AnnotationInvocationHandler 实例，把这个 map 传递给它。

最后，虚拟机将采用 JDK 动态代理机制生成一个目标注解的代理类，并初始化好处理器。

那么这样，一个注解的实例就创建出来了，它本质上就是一个代理类，你应当去理解好 AnnotationInvocationHandler 中 invoke 方法的实现逻辑，这是核心。一句话概括就是，通过方法名返回注解属性值。