system.gc()函数的作用,什么时候可以调用垃圾回收器?

发布网友发布时间：2024-10-19 09:18

共1个回答

热心网友时间：16小时前

在 OpenJDK17 下，`System.gc()` 函数在某些场景下是必要的，尤其是在与 Java NIO 配合使用时。当使用 NIO 中的 `FileChannel#map` 进行文件内存映射时，如果 JVM 虚拟内存空间不足，JVM 会尝试调用 `System.gc()` 强制触发垃圾回收，以释放内存。类似地，在通过 `ByteBuffer#allocateDirect` 申请堆外内存时，如果内存不足，`System.gc()` 会被调用来尝试回收资源以满足内存需求。

通常应避免在应用中主动调用 `System.gc()`，因为这会导致全量垃圾回收（Full GC）立即启动，给系统性能带来较大影响。但在 NIO 场景中，调用 `System.gc()` 是有必要的，尤其是针对 DirectByteBuffer。DirectByteBuffer 是 JVM 堆中的对象，它背后可能关联着大量 Native 内存。当这些 DirectByteBuffer 实例不再被引用时，垃圾回收器在回收对象的同时也会将 Cleaner 放入待处理队列，以便后续释放关联的 Native 内存。然而，DirectByteBuffer 实例由于体积小且长时间被应用程序持有，不容易达到触发全量垃圾回收的程度，导致关联的大量 Native 内存无法及时释放，可能引起内核 OOM 问题。

在 NIO 场景下，调用 `System.gc()` 可以主动触发全量垃圾回收，解决 DirectByteBuffer 实例累积导致的内存泄露问题。需要注意的是，`System.gc()` 并非直接触发垃圾回收，而是向 JVM 提示，后续垃圾回收器根据自身策略决定是否执行全量回收。不同垃圾回收器对 `System.gc()` 的响应方式不同，例如 SerialGC、ParallelGC、ZGC、G1、Shenandoah 等，它们分别通过调用特定堆类型（如 SerialHeap、ParallelScavengeHeap、ZCollectedHeap 等）的 `collect` 方法来执行回收操作。在默认情况下，`System.gc()` 会立即启动全量垃圾回收，而其他情况下，垃圾回收的触发则取决于垃圾回收器的配置与策略。