system.gc()不保证回收效果，判断依据是观测jvm实际行为：通过gc日志确认是否触发、memorymxbean观察内存使用趋势、referencequeue验证具体对象回收。
System.gc() 不会直接告诉你回收是否有效，它本身不返回任何结果，也不提供执行反馈。判断效果的关键在于“观测 JVM 实际行为”，而不是依赖调用本身。
看 GC 日志，而不是看 System.gc() 是否被调用
这是最可靠的方式。启用以下 JVM 参数后，每次 GC（无论是否由 System.gc() 触发）都会输出详细记录：
- -XX:+PrintGCDetails：显示每次 GC 的类型、耗时、各区域内存变化
- -XX:+PrintGCDateStamps：带上时间戳，便于定位调用后是否有对应事件
- -Xlog:gc*:stdout:time,uptime（JDK 10+ 推荐）：更结构化的日志格式
如果调用 System.gc() 后日志中没有新增 GC 行，说明 JVM 忽略了该建议；如果有，再比对 “Before” 和 “After” 的堆内存使用量，才能确认是否真有对象被回收。
用 MemoryMXBean 做趋势观察，而非单次快照
Runtime.getRuntime().freeMemory() 或 totalMemory() - freeMemory() 这类方法返回的是瞬时值，受 GC 异步性、内存碎片、TLAB 分配等影响，单次调用前后对比几乎无意义。
- 正确做法是：在对象置 null 后，间隔几毫秒到几十毫秒，多次采样 getHeapMemoryUsage().getUsed()
- 观察是否出现明显下降趋势（例如连续 3 次采样递减），才说明回收已发生
- 注意：即使回收发生，内存也可能未立即返还给操作系统（尤其 G1/ZGC），所以堆内 Used 下降 ≠ OS 层内存释放
用 ReferenceQueue 确认具体对象是否被回收
这是唯一能精确回答“某个对象有没有被回收”的方式，适用于调试和验证逻辑：
- 创建 WeakReference 或 PhantomReference，并关联 ReferenceQueue
- 将目标对象赋给 reference，随后置 null
- 调用 System.gc()（仅作提示），再轮询 queue.poll() —— 若返回非 null，则证明该对象已被回收
- PhantomReference 更适合此用途，因为它只在对象彻底不可达且 finalize 完成后入队
别被“内存没降”误导，先确认回收是否真有必要
很多情况下 System.gc() 没效果，不是因为失败，而是因为没必要：
- JVM 堆内存充足（比如只用了 30%），默认策略下会跳过 Full GC
- 对象还在新生代 Eden 区，Minor GC 尚未触发，System.gc() 通常不强制做 Minor GC
- 使用 ZGC 或 Shenandoah 等低延迟收集器时，System.gc() 被设计为静默忽略
- Docker 环境中若未设 -XX:MaxRAMPercentage，JVM 可能误判可用内存，导致建议被丢弃
