System.gc()不是内存碎片整理工具，也不能可靠用于性能测试，它仅是向JVM发出建议，现代GC（如G1、ZGC）通常忽略或弱化该请求，甚至可被-XX:+DisableExplicitGC禁用；真正影响碎片和性能的是对象生命周期设计与GC策略本身。
System.gc() 不是内存碎片整理工具，也不能可靠用于性能测试。它只是向 JVM 发出一个“建议”，现代 GC（如 G1、ZGC、Shenandoah）通常忽略或弱化该请求，甚至可被 -XX:+DisableExplicitGC 完全禁用。真正影响碎片和性能的，是对象生命周期设计与 GC 策略本身，而非人工触发。
内存碎片整理：System.gc 并不适用
堆内存碎片主要出现在老年代，尤其在使用 Parallel GC 或 CMS（已废弃）时较明显；而 G1 和 ZGC 本身具备区域化管理与并发整理能力，天然缓解碎片问题。System.gc() 即使触发 Full GC，也不保证执行压缩——例如 G1 默认只在必要时才做部分区域的 Evacuation，ZGC 更是全程无停顿、不依赖显式调用。
- Parallel GC 下调用 System.gc() 可能触发带压缩的 Full GC，但会引发长暂停，得不偿失
- G1 在 JDK 9+ 中默认将 System.gc() 降级为一次轻量级 Young GC，几乎不影响老年代或碎片
- ZGC/Shenandoah 完全无视 System.gc()，其回收节奏由堆使用率与延迟目标驱动
- 真正减少碎片的方式是：避免大对象频繁晋升、合理设置 -XX:MaxGCPauseMillis、启用 -XX:+UseG1GC -XX:G1HeapRegionSize=适当值（G1）等参数调优
性能测试中慎用 System.gc()
在基准测试（如 JMH）中，有人试图用 System.gc() “清理干净再测”，但这会严重扭曲结果：
- GC 时间计入测试耗时，导致吞吐量/延迟指标失真
- 不同 JVM 版本对 System.gc() 响应差异极大，跨环境不可复现
- JMH 本身提供
@Fork(jvmArgsAppend = "-XX:+PrintGCDetails")和内置 GC 预热机制，无需手动干预 - 若需排除前序干扰，应使用
@Setup(Level.Iteration)初始化 + 显式置 null + 等待几轮 GC（通过 MBean 观察），而非强求一次 System.gc()
极少数仍可能观察到效果的边界场景
这些不是推荐做法，而是历史遗留或受限环境下的“现象级”行为，不可依赖：
- MappedByteBuffer 文件锁释放：底层 OS 映射资源未及时解绑时，调用 System.gc() 可能加速 Cleaner 执行，从而允许 delete 临时文件（如知识库中示例）
- DirectByteBuffer 堆外内存回收：当大量 DirectBuffer 分配后未及时 clean，且 JVM 启用了 -XX:+DisableExplicitGC 以外配置时，偶尔可见效果
- 嵌入式或老版本 JDK（≤8u40）+ Serial GC：资源极度受限设备上，System.gc() 触发概率高，但仍是“碰运气”
替代方案：比 System.gc() 更可控的做法
与其等待不确定的 GC 建议，不如从根源控制内存行为：
- 缓存类场景用
WeakHashMap或SoftReference，让 GC 自然回收，避免手动干预 - 大集合对象及时
clear()或remove()，切断引用链，而不是等 GC“扫” - NIO Buffer、InputStream/OutputStream、Connection 等务必
close()或clean()，它们的资源不在堆内，System.gc() 无效 - 排查内存压力？看 GC 日志（
-Xlog:gc*:file=gc.log）、堆直方图（jcmd <pid> VM.native_memory summary）、MAT 分析引用链，而非加 System.gc()
