Java的Runtime机制（三）：垃圾回收（GC）在上篇文章《Java的Runtime机制（二）：核心功能》里简单提到

在上篇文章《Java的Runtime机制（二）：核心功能》里简单提到了GC，这篇文章会对GC有个全面的解析。

在 Java 中，gc() 方法是与垃圾回收（Garbage Collection, GC）直接交互的入口，但其行为本质上是 建议性 而非强制性的。以下是关于 gc() 的全面解析：

1. `gc()` 方法的定义与作用

方法签名：

public native void gc(); // 在 Runtime 类中定义

功能：向 JVM 发送垃圾回收的建议，触发垃圾回收机制尝试释放未使用的内存。
等价调用：
System.gc() 本质上调用 Runtime.getRuntime().gc()，两者功能一致，但 System.gc() 更常用。

2. 垃圾回收的底层原理

垃圾回收的触发条件

JVM 的垃圾回收是自动管理的，其触发条件由以下因素决定：

堆内存不足：当分配新对象时，若堆内存不足，JVM 会自动触发 GC。
内存分配策略：不同的垃圾收集器（如 G1、CMS、ZGC）有不同的内存分配和回收策略。
显式调用 gc() ：开发者通过代码建议 JVM 执行 GC。

`gc()` 方法的本质

仅发送建议：调用 gc() 不会强制 JVM 立即执行垃圾回收。
JVM 的自主权：JVM 可能完全忽略此建议，或仅执行部分回收（如仅回收年轻代）。

3. `gc()` 的实际行为与限制

3.1 不确定性

回收时间不确定：调用 gc() 后，无法预测 JVM 何时执行回收，甚至可能完全不执行。
回收范围不确定：可能只回收部分内存（如年轻代），而非整个堆。

3.2 与垃圾收集器的关系

不同垃圾收集器对 gc() 的响应不同：

串行/并行收集器：可能立即执行 Full GC（暂停所有应用线程）。
G1/ZGC：可能仅执行部分阶段的回收，或完全忽略。
CMS（已废弃） ：可能触发并发标记阶段。

3.3 JVM 参数的干预

禁用显式 GC：通过 -XX:+DisableExplicitGC 参数可禁止 System.gc() 触发垃圾回收。
强制 Full GC：通过 -XX:+ExplicitGCInvokesConcurrent（仅限某些收集器）可让 gc() 触发并发回收而非完全 STW（Stop-The-World）。

4. `gc()` 的使用场景

合理场景

性能测试与调试：

在内存泄漏分析时，手动触发 GC 以观察内存变化。

示例：

long before = Runtime.getRuntime().freeMemory();
System.gc(); // 建议回收
long after = Runtime.getRuntime().freeMemory();
System.out.println("回收释放内存: " + (after - before) + " bytes");

内存敏感型操作前：
- 在处理大型数据或文件前，尝试释放内存以减少 OutOfMemoryError 风险。
- 示例：
```
System.gc(); // 建议回收
processLargeData(); // 执行内存密集型操作
```
资源释放验证：
- 验证对象是否被正确释放（需结合弱引用或 finalize() 方法）。

不推荐场景

频繁调用：可能导致性能下降（频繁 STW 暂停）。
依赖 gc() 管理内存：Java 设计初衷是自动内存管理，手动干预通常弊大于利。

5. 代码示例与验证

示例 1：观察 `gc()` 的效果

public class GCDemo {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        
        // 1. 初始化内存状态
        long total = rt.totalMemory();
        long free1 = rt.freeMemory();
        System.out.println("初始空闲内存: " + free1 + " bytes");

        // 2. 分配大量对象
        List<byte[]> list = new ArrayList<>();
        for (int i = 0; i < 1000; i++) {
            list.add(new byte[1024 * 1024]); // 分配 1MB
        }
        
        // 3. 释放引用（对象变为可回收状态）
        list = null;

        // 4. 调用 gc()
        long free2 = rt.freeMemory();
        System.out.println("分配后空闲内存: " + free2 + " bytes");
        
        System.gc(); // 建议回收
        
        // 5. 等待 GC 完成（非可靠方法，仅用于演示）
        try { Thread.sleep(1000); } catch (InterruptedException e) {}
        
        long free3 = rt.freeMemory();
        System.out.println("GC 后空闲内存: " + free3 + " bytes");
    }
}

可能输出

初始空闲内存: 253223424 bytes
分配后空闲内存: 132120 bytes
GC 后空闲内存: 253223424 bytes

注意事项

输出结果因 JVM 实现、堆大小参数和垃圾收集器不同而异。
Thread.sleep(1000) 仅用于演示，实际无法保证 GC 完成。

6. 关键注意事项

性能风险：
- Full GC 会导致 STW 暂停（所有应用线程暂停），频繁调用可能显著降低吞吐量。

不可靠性：

无法依赖 gc() 保证内存释放，如以下代码可能失败：

try {
    byte[] hugeData = new byte[Integer.MAX_VALUE]; // 假设内存不足
} catch (OutOfMemoryError e) {
    System.gc(); // 尝试回收
    hugeData = new byte[Integer.MAX_VALUE]; // 仍可能抛出 OOM
}

替代方案：
- 使用 java.lang.ref 包中的 弱引用（WeakReference） 或 软引用（SoftReference） 更优雅地管理内存。
- 优化代码逻辑，减少内存占用（如对象池、缓存策略）。

7. 总结

gc() 的本质：是开发者与 JVM 垃圾回收机制交互的“建议按钮”，而非强制命令。
适用场景：调试、性能测试或特定内存敏感操作前，但需谨慎使用。
最佳实践：
- 优先依赖 JVM 的自动垃圾回收。
- 通过 JVM 参数（如 -Xmx、-Xms）优化堆内存配置。
- 避免在业务逻辑中频繁调用 gc()。

Java的Runtime机制（三）：垃圾回收（GC）

1. gc() 方法的定义与作用