system.gc() 仅是向jvm发出的轻量级gc提示，其执行与否由jvm自主决定；需配合gc日志、memorymxbean、weakreference及特定jvm参数（如-xx:+explicitgcinvokesconcurrent）进行可观测性验证。
System.gc() 不是控制回收的开关，而是向 JVM 发出的一次轻量级提示。它本身不决定是否回收、何时回收、回收哪些对象——这些全由 JVM 根据当前堆状态、GC 算法和参数配置自主决策。想通过它“观察回收效率”，关键不在调用本身，而在如何搭配可观测手段与合理参数，把这次提示变成一次可验证的行为探针。
启用可追踪的 GC 日志是前提
没有日志，System.gc() 就像发了一条没回执的消息。必须配合 JVM 参数打开详细输出：
- Java 9+ 推荐：-Xlog:gc*:file=gc.log:time,tags,level，能记录每次 GC 类型、耗时、各代内存变化、晋升与回收量
- Java 8 可用：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log
- 加上 -XX:+UnlockDiagnosticVMOptions -XX:+PrintReferenceGC，可额外看到软/弱/虚引用的清理情况
调用 System.gc() 后，不要看控制台是否“卡顿”，而要查日志里有没有新增一行 GC 记录，以及前后堆使用量是否出现回落。
用 MemoryMXBean 验证实际内存变化
Runtime.getRuntime().freeMemory() 或 totalMemory() - freeMemory() 这类方法返回的是 JVM 管理的堆视图，不是操作系统真实释放量。更可靠的方式是：
- 获取 ManagementFactory.getMemoryMXBean()
- 调用 getHeapMemoryUsage().getUsed() 获取当前已用堆内存
- 在置 null 大对象后、调用 System.gc() 前后，间隔几毫秒采样 2–3 次（避免单次抖动干扰）
- 对比趋势：若 Used 值明显下降（比如从 120MB → 95MB），且日志中对应一次 Full GC 或混合 GC，则说明该次提示被响应并生效
配合引用类型做精准对象级验证
System.gc() 无法告诉你“某个对象是否被回收”，但 WeakReference + ReferenceQueue 可以：
- 创建大数组或对象时，用 WeakReference
ref = new WeakReference(bigArray) 包装 - 执行 bigArray = null 断开强引用
- 调用 System.gc()（仅作辅助触发）
- 立刻检查 ref.get() == null，若为 true，说明该对象已被回收
- 更严谨的做法：把 ref 注册到 ReferenceQueue，监听其入队事件，这是唯一能确认“具体对象回收完成”的方式
调整 JVM 参数提升响应可见性
默认配置下，G1 收集器常忽略 System.gc()；ZGC 和 Shenandoah 更倾向于完全跳过。若需让提示更易被观测，可临时启用以下参数（仅用于测试/诊断，非生产）：
- -XX:+ExplicitGCInvokesConcurrent：让 CMS 或 G1 把显式调用转为并发 GC（降低 STW 影响）
- -XX:-DisableExplicitGC：确保未被全局禁用（某些 JDK 发行版如 Dragonwell 默认开启 DisableExplicitGC）
- -Xmx512m -Xms512m：固定堆大小，避免扩容干扰 GC 触发节奏
- -XX:MaxGCPauseMillis=100：让 GC 更积极响应内存压力，提高 System.gc() 被采纳的概率
注意：这些参数不改变回收逻辑本质，只让 JVM 在满足条件时更愿意响应提示，便于你观察机制而非操控机制。
