内存结构与垃圾回收

😉 本文共6125字，阅读时间约12min

目录

• 内存结构
  • JVM、JRE、JDK关系
  • 学习路线
  • 程序计数器
  • 虚拟机栈
    • StackOverflow
    • 线程运行诊断
    • jstack命令
  • 本地方法栈
  • 堆
    • OOM
      • 出现原因
    • 堆内存诊断
  • 方法区
    • 运行时常量池
    • 方法区内容
    • 方法区OOM
    • 方法区垃圾回收
    • 为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace)
  • 串池
    • 串池为什么要调整位置？
    • 串池作用
    • 字符串拼接原理
    • 字符串延迟加载
    • intern方法
    • 串池垃圾回收
    • StringTable 性能调优
  • 直接内存
    • 使用直接内存的好处
    • 直接内存回收原理
• 垃圾回收
  • 如何判断对象可回收？
    • 引用计数法
    • 可达性分析
  • 四种引用
    • 引用继承关系图
    • 四种引用特点
      • 强引用
      • 软引用
      • 弱引用
      • 虚引用
      • 终结器引用（FinalReference）
    • 引用队列
    • 适用场景
    • finalize()方法
  • 垃圾回收算法
    • 标记清除
    • 标记整理
    • 复制
  • 分代垃圾回收
    • 什么是分代垃圾回收
    • 为什么要进行分代垃圾回收
    • 如何进行分代垃圾回收
    • 空间分配担保策略
    • Full GC触发条件
    • 频繁Full GC可能的原因
    • 相关 JVM 参数
• 垃圾回收器
  • 几种常见的垃圾回收器
  • 什么是STW
  • 串行
    • 安全点
    • 几种收集器
  • 吞吐量优先
    • Parallel Scavenge 收集器
    • Parallel Old 收集器
  • 响应时间优先
    • CMS收集器
  • 同时注重吞吐量和低延迟（响应时间）
    • G1收集器

内存结构

JVM、JRE、JDK关系

• JVM：运行在操作系统上
• JRE：包含了JVM和基础类库
• JDK：包含JRE的基础上，多了一些编译工具

学习路线

• Java Class 编译后的字节码文件
• 类加载器：加载字节码文件到JVM内存结构里
• 内存结构
  • 堆、元空间、虚拟机栈、本地方法栈、程序计数器（后三个线程私有）
  • 本地方法栈：JVM执行的native方法，这些方法由非java实现。比如与操作系统交互时用到
• 执行引擎：解释器逐行执行方法字节码，热点代码如频繁调用的方法，有JIT即时编译器直接编译成机器码。GC进行垃圾回收，回收堆中对象。

程序计数器

1. PC，程序计数器，记录下一条jvm的执行地址
2. 线程私有，不会内存溢出
3. 作用：
   1. 解释器会解释指令为机器码交给 cpu 执行，程序计数器会记录下一条指令的地址行号，这样下一次解释器会从程序计数器拿到指令然后进行解释执行。
   2. 多线程，上下文切换时，程序计数器会记录当前线程下一行指令的地址。

虚拟机栈

1. 每个线程都有自己的虚拟机栈，每个栈由多个栈帧组成，是调用方法时所占的内存
2. 每个线程只能有一个活动栈帧，对应当前正在执行的方法
3. 辨析：
   1. 垃圾回收不涉及栈内存，方法调用结束后会自动弹出栈帧
   2. 栈内存不是越大越好。栈内存越大，可以支持更多的递归调用，但是可执行的线程数就会越少。
   3. 方法内部局部变量是否线程安全？
      1. 如果方法内部的变量没有逃离方法的作用访问，它是线程安全的
      2. 如果是局部变量引用了对象，并逃离了方法的访问，那就要考虑线程安全问题。

StackOverflow

栈内存溢出，由栈帧过大，过多引起。

线程运行诊断

案例一：cpu 占用过多
解决方法：Linux 环境下运行某些程序的时候，可能导致 CPU 的占用过高，这时需要定位占用 CPU 过高的线程

• top 命令，查看是哪个进程占用 CPU 过高
• ps H -eo pid, tid（线程id）, %cpu | grep 刚才通过 top 查到的进程号 通过 ps 命令进一步查看是哪个线程占用 CPU 过高
• jstack 进程 id 通过查看进程中的线程的 nid ，刚才通过 ps 命令看到的 tid 来对比定位，注意 jstack 查找出的线程 id 是 16 进制的，需要转换。

jstack命令

stack是JVM自带的Java堆栈跟踪工具，用于生成虚拟机当前时刻的线程快照。

线程快照是每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因， 如线程间死锁、死循环、请求外部资源导致的长时间等待等问题。

查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么，或者等待什么资源。

本地方法栈

本地方法栈：服务JVM执行的native方法，这些方法由非java实现，C或C++实现的。比如与操作系统交互时用到。

堆

1. new出来的对象都在堆内存
2. 特点
   1. 它是线程共享，堆内存中的对象都需要考虑线程安全问题
   2. 有GC机制

OOM

java.lang.OutofMemoryError ：java heap space. 堆内存溢出

可以使用 -Xmx8m 来指定堆内存大小。

OOM也可能是方法区空间溢出了

出现原因

1. 申请内存速度超出GC释放速度，导致空间不够。
   1. 比如往内存加载超大对象
   2. 循环创建大量对象
2. 内存泄漏
   1. 资源对象没关闭，比如File没关闭
   2. static修饰的大集合强引用没清理

堆内存诊断

1. jps 工具
   查看当前系统中有哪些 java 进程及其进程id

2. jmap 工具
   查看堆内存占用情况 jmap - heap 进程id

jmap（Java Memory Map）主要用于查看 jvm 内存，是 jvm 自带的一种内存映像工具。

3. jconsole 工具
   图形界面的，多功能的监测工具，可以连续监测

方法区

运行时常量池

运行时常量池，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。

当该类被加载以后，对应的字节码文件的常量池信息就会放入运行时常量池，并把里面的符号地址变为真实地址。

注意常量池是字节码class文件的一部分。

一个java源文件中的类、接口，编译后产生一个字节码文件。二进制字节码包含类的基本信息，常量池，类方法定义，包含了虚拟机的指令。

而Java中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用。

常量池、可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

存放的内容有字面量，字符串值，类引用，字段引用，方法引用(这几个都是符号引用)。

方法区内容

1. 方法区内部包含：

   1. 运行时常量池。
   2. 类信息：类结构、字段和方法数据，以及方法和构造函数代码
      1. 类信息：类的全限定名（包名+类名）、父类名称、修饰符如public
      2. 字段、方法

2. 线程共享，方法区是一个概念，1.8以前由永久代实现，1.8由元空间实现。

   1. 串池在1.8前在永久代的运行时常量池里，1.8后在堆里。
   2. 元空间不在虚拟机设置的内存中，而是使用本地内存
      

方法区OOM

• 1.8 之前会导致永久代内存溢出
• 1.8 之后会导致元空间内存溢出

方法区垃圾回收

一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类。HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。

为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace)

1. 整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。
2. 元空间里面存放的是类的元数据，这样加载多少类的元数据就不由 MaxPermSize 控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。

串池

串池，StringTable，字符串常量池。hashtable结构，不能扩容。

串池为什么要调整位置？

jdk7中将StringTable放到了堆空间中。因为永久代的回收效率很低，在full gc的时候才会触发。而full gc是老年代的空间不足、永久代不足时才会触发。

这就导致StringTable回收效率不高。而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存。

串池作用

• 运行时常量池中的字符串仅是符号，只有在被用到时才会转化为加载对象放入串池
  • 这就是字符串延迟加载
• 利用串池的机制，来避免重复创建字符串对象

字符串拼接原理

• 字符串常量拼接的原理是编译器优化

• 字符串变量拼接的原理是StringBuilder

String s1 = "a",s2 = "b";
String s3 = "a" + "b";
String s4 = s1 +s2; // s3 != s4

字符串延迟加载

运行时常量池中的字符串仅是符号，只有在被用到时才会转化为加载对象放入串池

intern方法

• 可以使用intern方法，主动将串池中还没有的字符串对象放入串池中。
  • 如果串池中没有该字符串对象，则放入成功。
  • 如果有该字符串对象，则放入失败。
  • 无论放入是否成功，都会返回串池中的字符串对象

注意：此时如果调用 intern 方法成功，堆内存与串池中的字符串对象是同一个对象；如果失败，则不是同一个对象。

public class Main {
	public static void main(String[] args) {
		// 堆中创建新对象"a"、"b"、"ab"，并返回引用
        // "ab"不在串池，因为串池只存常量字符串, 现在是拼接后new出来的
		String str = new String("a") + new String("b");  // ["a","b"]
		
        // 将"ab"放入串池，无论成功失败都返回串池中的引用
		String st2 = str.intern();  // ["a","b","ab"]
		
        // 常量池中的信息，都会被加载到运行时常量池中。
        // 此时运行时常量池中“ab”，此时还是符号，还没有变成Java中的对象
        // 延迟加载：只有执行到引用“ab”的代码，才会创建对象，并尝试将其放到串池。
		String str3 = "ab"; 

		System.out.println(str == st2);  // true
		System.out.println(str == str3); // true
	}
}

串池垃圾回收

触发垃圾回收时，串池中没有被引用的字符串常量会被回收

StringTable 性能调优

• 因为StringTable是由HashTable实现的，所以可以适当增加HashTable桶的个数，来减少哈希碰撞，降低链表长度。来减少字符串放入串池所需要的时间。-XX:StringTableSize=桶个数（最少设置为 1009 以上）。
• 通过 intern 方法让字符串入池，减少堆内存的使用

直接内存

Direct Memory

• 常见于 NIO 操作时，用于数据缓冲区
• 分配回收成本较高，但读写性能高
• 不受 JVM 内存回收管理

使用直接内存的好处

文件读写流程：

因为 java 不能直接操作文件管理，需要切换到内核态，使用本地方法进行操作，然后读取磁盘文件，会在系统内存中创建一个缓冲区，将数据读到系统缓冲区， 然后在将系统缓冲区数据，复制到 java 堆内存中。缺点是数据存储了两份，在系统内存中有一份，java 堆中有一份，造成了不必要的复制。

使用了 DirectBuffer 文件读取流程

直接内存是操作系统和 Java 代码都可以访问的一块区域，无需将代码从系统内存复制到 Java 堆内存，从而提高了效率。

直接内存回收原理

• 虚引用监测手动回收：直接内存的回收不是通过 JVM 的垃圾回收来释放的，而是通过unsafe.freeMemory 来手动释放。
  • 使用了 Unsafe 类来完成直接内存的分配回收，回收需要主动调用freeMemory 方法
  • ByteBuffer 实现内部使用了 Cleaner（继承了虚引用类型），由ReferenceHandler线程来监测 ByteBuffer对象 ，如果虚引用的实际对象（这里是 DirectByteBuffer ）被回收以后，就会调用 Cleaner 的 clean 方法，来清除直接内存中占用的内存。

垃圾回收

如何判断对象可回收？

引用计数法

当一个对象被引用时，就当引用对象的值加一，当值为 0 时，就表示该对象不被引用，可以被垃圾收集器回收。
这个引用计数法听起来不错，但是有一个弊端，如下图所示，循环引用时，两个对象的计数都为1，导致两个对象都无法被释放。

可达性分析

• JVM 中的垃圾回收器通过可达性分析来探索所有存活的对象
• 扫描堆中的对象，看能否沿着 GC Root 对象为起点的引用链找到该对象，如果找不到，则表示可以回收
• 所谓GCRoots就是一组必须活跃的引用，可以作为 GC Root 的对象
  • 虚拟机栈（栈帧中的本地变量表）中引用的对象。
  • 方法区中类静态属性引用的对象
  • 方法区中常量引用的对象
  • 本地方法栈中 JNI（即一般说的Native方法）引用的对象

• 对象被gc掉同时需要满足两个条件，一个是gc roots不可达，另一个是没必要执行finalize方法。

四种引用

强引用、软引用、弱引用、虚引用、终结器引用

引用继承关系图

强引用是Java的默认实现，它会尽可能长时间的存活于JVM内，当没有GC Root引用时，强引用变量引用的对象将被回收。

其他引用需要使用Reference的子类进行声明，一般的应用程序不会涉及到 Reference 编程， 但是了解这些知识会对理解 GC 的工作原理以及性能调优有一定帮助, 在实现一些基础性设施比如缓存时也可能会用到。

WeakReference<Object> weakReference = new WeakReference<Object>(referent, referenceQueue); 

四种引用特点

强引用

强引用指的是代码中普遍存在的Object obj=new Object()这类的引用。

只有所有 GC Roots 对象都不通过【强引用】引用该对象，该对象才能被垃圾回收。

软引用

仅有软引用引用该对象时，在垃圾回收后，内存仍不足时会再次触发垃圾回收。

可以配合引用队列来释放软引用自身

弱引用

仅有弱引用引用该对象时，在垃圾回收时，无论内存是否充足都会回收弱引用对象。

可以配合引用队列来释放弱引用自身。

虚引用

主要配合 ByteBuffer 使用，唯一作用是被引用对象回收时，会将虚引用入队。由 Reference Handler 线程调用虚引用相关方法释放直接内存。

必须配合引用队列使用

终结器引用（FinalReference）

为什么需要FinalReference？

因为jvm只能管理jvm内存空间，但是对于应用运行时需要的其它native资源(jvm通过jni暴漏出来的功能)：例如直接内存DirectByteBuffer，网络连接SocksSocketImpl，文件流FileInputStream等与操作系统有交互的资源，jvm就无能为力了，需要我们自己来调用释放这些资源方法来释放。

为了避免对象死了之后，程序员忘记手动释放这些资源，导致这些对象有的外部资源泄露，java提供了finalizer机制通过重写对象的finalizer方法，比如关闭socket连接，在这个方法里面执行释放对象占用的外部资源的操作。

帮助我们调用这个方法回收资源的线程就是我们在导出jvm线程栈时看到的名为Finalizer的守护线程。Finalizer其实是实现了析构函数的概念，我们在对象被回收前可以执行一些『收拾性』的逻辑，应该说是一个特殊场景的补充。

其内部配合引用队列使用，在垃圾回收时，终结器引用入队（被引用对象暂时没有被回收），再由 Finalizer 线程通过终结器引用找到被引用对象并调用它的 finalize 方法，第二次 GC 时才能回收被引用对象。

但是如果真的是用户忘记关闭了，那这些socket对象可能因为FinalizeThread迟迟没有执行到这些socket对象的finalize方法，对象占用的内存也迟迟得不到释放，而导致内存泄露。（所以不建议重写finalize()方法）

引用队列

如果WeakReference的get方法返回null了，那么这个WeakReference所关联的对象已经被释放了，但是这个WeakReference对象本身还是存在的，它会占用空间，为了避免内存泄漏。我们需要一个机制来确保WeakReference也能被释放。

如果在创建WeakReference的时候，在构造函数里传入一个ReferenceQueue，那么在这个WeakReference所引用的对象被回收之后，这个WeakReference会被自动插入到ReferenceQueue里来。于是我们可以在适当的时候（比方说后台开一个定时线程）去扫描这个ReferenceQueue，然后把队列里的无用的WeakReference全部清除掉。

适用场景

• 软引用：比如图片缓存
• 虚引用：比如那些需要手动释放

finalize()方法

finalize()是Object中的方法，当垃圾回收器将要回收对象所占内存时，该方法被调用，即当一个对象被虚拟机宣告死亡时会先调用它的finalize()方法，让此对象临终前交代点遗言，当然对象也可以趁机复活。

可达性分析算法中，要宣告一个对象真正的死亡，要经历两次标记的过程：

如果对象在经历可达性分析之后，发现没有与GC root相连的引用链，将会被第一次标记并且进行第一次筛选，筛选的条件是是否有必要执行finalize()方法，当对象没有finalize()方法或者虚拟机已经调用过finalize()方法，视为没有必要执行。

如果这个对象被判定为有必要执行finalize()方法，那么对象将会放置在一个F-Queue队列中，稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。finalize()方法是对象逃离死亡的最后一次机会，稍后GC将会对队列进行第二次小规标记，如果对象要finalize()拯救它，只需要与引用链上的任意一个对象建立关联即可，那么第二次标记的时候它将会被移出即将回收的集合，如果没逃脱，就会真正被回收。

书中记载，“它不是C/C++中的析构函数，而是Java刚诞生时为了使C/C++程序员更容易接受它所做出的一个妥协”。

垃圾回收算法

标记清除

Mark Sweep

• 速度较快
• 会产生内存碎片
  

标记整理

Mark Compact

• 速度慢
• 没有内存碎片
  

复制

Copy

• 不会有内存碎片
• 需要占用两倍内存空间
  

分代垃圾回收

什么是分代垃圾回收

Minor GC：当年轻代Eden区域满的时候会触发一次Minor GC，新生代的 GC。

Major GC：老年代的 GC。目前，只有 CMS GC 会有单独收集老年代的行为。

Full GC：整堆收集，收集整个 Java 堆和方法区的垃圾收集。

JVM 的调优的一个环节，就是垃圾收集，我们需要尽量的避免垃圾回收，因为在垃圾回收的过程中，容易出现 STW 的问题。

Major GC 和 Full GC 出现 STW 的时间是 Minor GC 的10倍以上。

为什么要进行分代垃圾回收

多轮回收后仍存活的对象在这一轮大概率也不会被回收，回收它们浪费性能。

新生代朝生夕死，回收效率高。

老年代存放生命周期比较长的对象，在新生代中经历了n次垃圾回收后仍然存活的对象就会被放到老年代中。此外，老年代的内存也比新生代大很多（比例大概是1：2）。full gc概率也低。

如何进行分代垃圾回收

• 新创建的对象首先分配在 eden 区
• 新生代空间不足时，触发 minor gc ，eden 区 和 from 区存活的对象使用 - copy 复制到 to 中，存活的对象年龄加一，然后交换 from to
• minor gc 会引发 stop the world，暂停其他线程，等垃圾回收结束后，恢复用户线程运行
• 当幸存区对象的寿命超过阈值时，会晋升到老年代，最大的寿命是 15（4bit）
• 当老年代空间不足时，会先触发 minor gc，如果空间仍然不足，那么就触发 full fc ，停止的时间更长！（比如当新生代放不下新对象时，对象会直接放到老年代，这种情况下如果老年代也放不下，先触发minor gc，最好能让新对象待在新生代）。

空间分配担保策略

在发生Minor GC之前，检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。

• 如果大于，则此次Minor GC是安全的
• 如果小于，则虚拟机会查看-X:HandlePromotionFailure设置值是否允许担保失败。
  • 不允许，直接Full GC
  • 允许，检查最大可用连续空间是否大于历代晋升的对象平均大小
    • 大于，进行一次有风险的Minor GC
    • 小于，直接Full GC

Full GC触发条件

1. 老年代空间不足，引起Full GC
   1. 大对象直接进入老年代
   2. 经历过多次Minor GC仍存在的对象进入老年代
   3. Minor GC时，动态对象年龄判定机制会将对象提前转移老年代。
   4. Minor GC时，Eden和From Space区向To Space区复制时，大于To Space区可用内存，会直接把对象转移到老年代
2. 空间分配担保机制可能会触发Full GC，如上图
3. 调用System.gc()方法

频繁Full GC可能的原因

1. 堆内存分配过低
2. 集合类频繁加入大对象，比如图片等等

相关 JVM 参数

堆初始大小-Xms

堆最大大小-Xmx

新生代大小-Xmn

GC详情-XX:+PrintGCDetails -verbose:gc

FullGC 前 MinorGC-XX:+ScavengeBeforeFullGC

垃圾回收器

相关概念：

• 并行收集：指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
• 并发收集：指用户线程与垃圾收集线程同时工作（不一定是并行的可能会交替执行）。用户程序在继续运行，而垃圾收集程序运行在另一个 CPU 上
• 吞吐量：即 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值（吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 )），也就是。例如：虚拟机共运行 100 分钟，垃圾收集器花掉 1 分钟，那么吞吐量就是 99% 。

几种常见的垃圾回收器

1. 串行：

   1. 单线程
   2. 堆内存较小，适合个人电脑
   3. Serial + SerialOld

2. 吞吐量优先：

   1. 多线程
   2. 堆内存较大，多核CPU
   3. 单位时间内，STW 的时间最短 0.2 0.2 = 0.4，垃圾回收时间占比最低，这样就称吞吐量高
   4. Parallel Scavenge 收集器 + Parallel Old 收集器

3. 响应时间优先：

   1. 多线程
   2. 堆内存较大，多核CPU
   3. 尽可能让单次 STW 的时间最短 0.1 0.1 0.1 0.1 0.1 = 0.5
   4. 新生代可搭配ParNew收集器 + 老年代用CMS收集器

4. 同时注重吞吐量和低延迟（响应时间）：

   1. G1收集器
   • 超大堆内存（内存大的），会将堆内存划分为多个大小相等的区域
   • 整体上是标记-整理算法，两个区域之间是复制算法

什么是STW

Java中Stop-The-World机制简称STW，是在执行垃圾收集算法时，Java应用程序的其他所有线程都被挂起。Java中一种全局暂停现象，全局停顿，所有Java代码停止，native代码可以执行，但不能与JVM交互；这些现象多半是由于gc引起。

GC时的Stop the World(STW)是大家最大的敌人。

串行

安全点

让其他线程都在这个点停下来，以免垃圾回收时移动对象地址，使得其他线程找不到被移动的对象。因为是串行的，所以只有一个垃圾回收线程。且在该线程执行回收工作时，其他线程进入阻塞状态。需要STW（Stop The World）。

几种收集器

Serial收集器	ParNew 收集器（非串行）	Serial Old 收集器
	Serial 收集器的多线程版本	Serial 收集器的老年代版本
单线程	多线程	单线程
复制算法	复制算法	标记整理
STW	STW	STW

吞吐量优先

-XX:+UseParallelGC ~ -XX:+UsePrallerOldGC
* XX:MaxGCPauseMillis=ms 控制最大的垃圾收集停顿时间（默认200ms）
* XX:GCTimeRatio=rario 直接设置吞吐量的大小

Parallel Scavenge 收集器

吞吐量优先收集器，该收集器的目标是达到一个可控制的吞吐量。

新生代收集器、多线程并行、复制算法，很像ParNew，区别在于有GC自适应调节策略。

GC自适应调节策略：不需要手动指定新生代的大小、Eden 与 Survivor 区的比例、晋升老年代的对象年龄，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为 GC 的自适应调节策略。

Parallel Old 收集器

是 Parallel Scavenge 收集器的老年代版本，多线程，采用标记-整理算法。

响应时间优先

-XX:+UseConcMarkSweepGC ~ -XX:+UseParNewGC
-XX:+CMSScavengeBeforeRemark

CMS收集器

使用CMS 收集器。一种以获取最短回收停顿时间为目标的老年代收集器。

应用场景：适用于注重服务的响应速度，希望系统停顿时间最短，给用户带来更好的体验等场景下。如 web 程序、b/s 服务。

同时注重吞吐量和低延迟（响应时间）

G1收集器