JVM相关 - 深入理解 System.gc()

于 2021-07-20 14:34:27 发布
阅读量271 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： java 程序员 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Java_cola/article/details/118934582
本文深入分析了为何需要`System.gc()`，包括堆外内存回收、Weak/SoftReference的管理以及测试需求。探讨了不同GC处理方式如G1、ZGC和Shenandoah的响应。此外，还介绍了相关的JVM参数和如何通过WhiteBox API主动触发GC，同时提供了Java工程师面试题，覆盖初级到高级的技能考察。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

我们经常在面试中询问 System.gc() 究竟会不会立刻触发 Full GC，网上也有很多人给出了答案，但是这些答案都有些过时了。本文基于最新的 Java 的下一个即将发布的 LTS 版本 Java 17（ea）的源代码，深入解析 System.gc() 背后的故事。

为什么需要System.gc()

1. 使用并管理堆外内存的框架，需要 Full GC 的机制触发堆外内存回收

JVM 的内存，不止堆内存，还有其他很多块，通过 Native Memory Tracking 可以看到：

Native Memory Tracking:

Total: reserved=6308603KB, committed=4822083KB
-                 Java Heap (reserved=4194304KB, committed=4194304KB)
                            (mmap: reserved=4194304KB, committed=4194304KB) 
 
-                     Class (reserved=1161041KB, committed=126673KB)
                            (classes #21662)
                            (  instance classes #20542, array classes #1120)
                            (malloc=3921KB #64030) 
                            (mmap: reserved=1157120KB, committed=122752KB) 
                            (  Metadata:   )
                            (    reserved=108544KB, committed=107520KB)
                            (    used=105411KB)
                            (    free=2109KB)
                            (    waste=0KB =0.00%)
                            (  Class space:)
                            (    reserved=1048576KB, committed=15232KB)
                            (    used=13918KB)
                            (    free=1314KB)
                            (    waste=0KB =0.00%)
 
-                    Thread (reserved=355251KB, committed=86023KB)
                            (thread #673)
                            (stack: reserved=353372KB, committed=84144KB)
                            (malloc=1090KB #4039) 
                            (arena=789KB #1344)
 
-                      Code (reserved=252395KB, committed=69471KB)
                            (malloc=4707KB #17917) 
                            (mmap: reserved=247688KB, committed=64764KB) 
 
-                        GC (reserved=199635KB, committed=199635KB)
                            (malloc=11079KB #29639) 
                            (mmap: reserved=188556KB, committed=188556KB) 
 
-                  Compiler (reserved=2605KB, committed=2605KB)
                            (malloc=2474KB #2357) 
                            (arena=131KB #5)
 
-                  Internal (reserved=3643KB, committed=3643KB)
                            (malloc=3611KB #8683) 
                            (mmap: reserved=32KB, committed=32KB) 
 
-                     Other (reserved=67891KB, committed=67891KB)
                            (malloc=67891KB #2859) 
 
-                    Symbol (reserved=26220KB, committed=26220KB)
                            (malloc=22664KB #292684) 
                            (arena=3556KB #1)
 
-    Native Memory Tracking (reserved=7616KB, committed=7616KB)
                            (malloc=585KB #8238) 
                            (tracking overhead=7031KB)
 
-               Arena Chunk (reserved=10911KB, committed=10911KB)
                            (malloc=10911KB) 
 
-                   Tracing (reserved=25937KB, committed=25937KB)
                            (malloc=25937KB #8666) 
 
-                   Logging (reserved=5KB, committed=5KB)
                            (malloc=5KB #196) 
 
-                 Arguments (reserved=18KB, committed=18KB)
                            (malloc=18KB #486) 
 
-                    Module (reserved=532KB, committed=532KB)
                            (malloc=532KB #3579) 
 
-              Synchronizer (reserved=591KB, committed=591KB)
                            (malloc=591KB #4777) 
 
-                 Safepoint (reserved=8KB, committed=8KB)
                            (mmap: reserved=8KB, committed=8KB)
  • Java Heap: 堆内存，即-Xmx限制的最大堆大小的内存。
  • Class：加载的类与方法信息，其实就是 metaspace，包含两部分： 一是 metadata，被-XX:MaxMetaspaceSize限制最大大小，另外是 class space，被-XX:CompressedClassSpaceSize限制最大大小
  • Thread：线程与线程栈占用内存，每个线程栈占用大小受-Xss限制，但是总大小没有限制。
  • Code：JIT 即时编译后（C1 C2 编译器优化）的代码占用内存，受-XX:ReservedCodeCacheSize限制
  • GC：垃圾回收占用内存，例如垃圾回收需要的 CardTable，标记数，区域划分记录，还有标记 GC Root 等等，都需要内存。这个不受限制，一般不会很大的。
  • Compiler：C1 C2 编译器本身的代码和标记占用的内存，这个不受限制，一般不会很大的
  • Internal：命令行解析，JVMTI 使用的内存，这个不受限制，一般不会很大的
  • Symbol: 常量池占用的大小，字符串常量池受-XX:StringTableSize个数限制，总内存大小不受限制
  • Native Memory Tracking：内存采集本身占用的内存大小，如果没有打开采集（那就看不到这个了，哈哈），就不会占用，这个不受限制，一般不会很大的
  • Arena Chunk：所有通过 arena 方式分配的内存，这个不受限制，一般不会很大的
  • Tracing：所有采集占用的内存，如果开启了 JFR 则主要是 JFR 占用的内存。这个不受限制，一般不会很大的
  • Logging，Arguments，Module，Synchronizer，Safepoint，Other，这些一般我们不会关心。

除了 Native Memory Tracking 记录的内存使用，还有两种内存 Native Memory Tracking 没有记录，那就是：

  • Direct Buffer：直接内存
  • MMap Buffer：文件映射内存

针对除了堆内存以外，其他的内存，有些也是需要 GC 的。例如：MetaSpace，CodeCache，Direct Buffer，MMap Buffer 等等。早期在 Java 8 之前的 JVM，对于这些内存回收的机制并不完善，很多情况下都需要 FullGC 扫描整个堆才能确定这些区域中哪些内存可以回收。

有一些框架，大量使用并管理了这些堆外空间。例如 netty 使用了 Direct Buffer，Kafka 和 RocketMQ 使用了 Direct Buffer 和 MMap Buffer。他们都是提前从系统申请好一块内存，之后管理起来并使用。在空间不足时，继续向系统申请，并且也会有缩容。例如 netty，在使用的 Direct Buffer 达到-XX:MaxDirectMemorySize的限制之后，则会先尝试将不可达的Reference对象加入Reference链表中，依赖Reference的内部守护线程触发可以被回收DirectByteBuffer关联的Cleaner的run()方法。如果内存还是不足， 则执行System.gc()，期望触发full gc，来回收堆内存中的DirectByteBuffer对象来触发堆外内存回收，如果还是超过限制，则抛出java.lang.OutOfMemoryError.

2. 使用了 WeakReference， SoftReference 的程序，需要相应的 GC 回收。

对于 WeakReference，只要发生 GC，无论是 Young GC 还是 FullGC 就会被回收。SoftReference 只有在 FullGC 的时候才会被回收。当我们程序想主动对于这些引用进行回收的时候，需要能触发 GC 的方法，这就用到了System.gc()。

3. 测试，学习 JVM 机制的时候

有些时候，我们为了测试，学习 JVM 的某些机制，需要让 JVM 做一次 GC 之后开始，这也会用到System.gc()。但是其实有更好的方法，后面你会看到。

System.gc() 背后的原理

System.gc()实际上调用的是RunTime.getRunTime().gc():

public static void gc() {
    Runtime.getRuntime().gc();
}

这个方法是一个 native 方法：

public native void gc();

对应 JVM 源码：

JVM_ENTRY_NO_ENV(void, JVM_GC(void))
  JVMWrapper("JVM_GC");
  //如果没有将JVM启动参数 DisableExplicitGC 设置为 false，则执行 GC，GC 原因是 System.gc 触发，对应 GCCause::_java_lang_system_gc
  if (!DisableExplicitGC) {
    Universe::heap()->collect(GCCause::_java_lang_system_gc);
  }
JVM_END

首先，根据 DisableExplicitGC 这个 JVM 启动参数的状态，确定是否会 GC，如果需要 GC，不同 GC 会有不同的处理。

1. G1 GC 的处理

如果是 System.gc() 触发的 GC，G1 GC 会根据 ExplicitGCInvokesConcurrent 这个 JVM 参数决定是默认 GC （轻量 GC，YoungGC）还是 FullGC。

参考代码g1CollectedHeap.cpp：

//是否应该并行 GC，也就是较为轻量的 GC，对于 GCCause::_java_lang_system_gc，这里就是判断 ExplicitGCInvokesConcurrent 这个 JVM 是否为 true
if (should_do_concurrent_full_gc(cause)) {
    return try_collect_concurrently(cause,
                                    gc_count_before,
                                    old_marking_started_before);
}// 省略其他这里我们不关心的判断分支
 else {
    //否则进入 full GC
    VM_G1CollectFull op(gc_count_before, full_gc_count_before, cause);
    VMThread::execute(&op);
    return op.gc_succeeded();
}

2. ZGC 的处理

直接不处理，不支持通过 System.gc() 触发 GC。

参考源码：zDriver.cpp

void ZDriver::collect(GCCause::Cause cause) {
  switch (cause) {
  //注意这里的 _wb 开头的 GC 原因，这代表是 WhiteBox 触发的，后面我们会用到，这里先记一下
  case GCCause::_wb_young_gc:
  case GCCause::_wb_conc_mark:
  case GCCause::_wb_full_gc:
  case GCCause::_dcmd_gc_run:
  case GCCause::_java_lang_system_gc:
  case GCCause::_full_gc_alot:
  case GCCause::_scavenge_alot:
  case GCCause::_jvmti_force_gc:
  case GCCause::_metadata_GC_clear_soft_refs:
    // Start synchronous GC
    _gc_cycle_port.send_sync(cause);
    break;

  case GCCause::_z_timer:
  case GCCause::_z_warmup:
  case GCCause::_z_allocation_rate:
  case GCCause::_z_allocation_stall:
  case GCCause::_z_proactive:
  case GCCause::_z_high_usage:
  case GCCause::_metadata_GC_threshold:
    // Start asynchronous GC
    _gc_cycle_port.send_async(cause);
    break;

  case GCCause::_gc_locker:
    // Restart VM operation previously blocked by the GC locker
    _gc_locker_port.signal();
    break;

  case GCCause::_wb_breakpoint:
    ZBreakpoint::start_gc();
    _gc_cycle_port.send_async(cause);
    break;

  //对于其他原因，不触发GC，GCCause::_java_lang_system_gc 会走到这里
  default:
    // Other causes not supported
    fatal("Unsupported GC cause (%s)", GCCause::to_string(cause));
    break;
  }
}

3. Shenandoah GC 的处理

Shenandoah 的处理和 G1 GC 的类似，先判断是不是用户明确触发的 GC，然后通过 DisableExplicitGC 这个 JVM 参数判断是否可以 GC（其实这个是多余的，可以去掉，因为外层JVM_ENTRY_NO_ENV(void, JVM_GC(void))已经处理这个状态位了）。如果可以，则请求 GC，阻塞等待 GC 请求被处理。然后根据 ExplicitGCInvokesConcurrent 这个 JVM 参数决定是默认 GC （轻量并行 GC，YoungGC）还是 FullGC。

参考源码shenandoahControlThread.cpp

void ShenandoahControlThread::request_gc(GCCause::Cause cause) {
  assert(GCCause::is_user_requested_gc(cause) ||
         GCCause::is_serviceability_requested_gc(cause) ||
         cause == GCCause::_metadata_GC_clear_soft_refs ||
         cause == GCCause::_full_gc_alot ||
         cause == GCCause::_wb_full_gc ||
         cause == GCCause::_scavenge_alot,
         "only requested GCs here");
  //如果是显式GC（即如果是GCCause::_java_lang_system_gc，GCCause::_dcmd_gc_run，GCCause::_jvmti_force_gc，GCCause::_heap_inspection，GCCause::_heap_dump中的任何一个）
  if (is_explicit_gc(cause)) {
    //如果没有关闭显式GC，也就是 DisableExplicitGC 为 false
    if (!DisableExplicitGC) {
      //请求 GC
      handle_requested_gc(cause);
    }
  } else {
    handle_requested_gc(cause);
  }
} 
</
最低0.47元/天 解锁文章
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值