system.gc()仅是向jvm发出的垃圾回收建议，是否执行、何时执行及执行类型（minor/full gc）完全由jvm自主决定；现代jdk（如17+ g1/zgc）中常被忽略或降级为nop，真实作用是信号而非开关。
System.gc() 不会触发任何确定的回收动作，它只是向 JVM 发出一次轻量级建议，是否响应、何时响应、以何种方式响应（Minor GC / Full GC / 完全忽略），完全由 JVM 当前运行状态和垃圾收集器策略决定。
它不是命令，而是信号
调用 System.gc() 等价于 Runtime.getRuntime().gc()，底层进入 JVM_GC() 函数。但该函数开头就会检查 -XX:+DisableExplicitGC 参数；若启用，直接跳过。即使未禁用，JVM 仍会根据以下条件自主决策：
- 当前堆内存使用率是否接近回收阈值
- 上一次 GC 是否刚完成，JVM 是否处于 GC 抑制期
- 所用 GC 算法是否响应显式请求（G1 默认忽略，CMS 可通过 -XX:+ExplicitGCInvokesConcurrent 转为并发模式）
现代 JDK 中它常被降级为 NOP
从 JDK 8u40 起，HotSpot 默认启用 -XX:+DisableExplicitGC；部分发行版（如 Alibaba Dragonwell）默认开启；Azul Zing 甚至完全移除响应逻辑。在 JDK 17+ 默认 G1 或 ZGC 下，System.gc() 大概率被忽略或延迟数百毫秒后才酌情参与混合回收，不保证类型、不保证执行、不提供反馈。
真正可观测的回收时机靠日志与引用队列
想确认不可达对象是否被回收，不能依赖 System.gc() 的调用，而应借助：
- GC 日志：启用 -XX:+PrintGCDetails -XX:+PrintGCDateStamps，观察每次 GC 的起始时间、类型、前后堆占用变化
- MemoryMXBean：调用 getHeapMemoryUsage().getUsed() 多次采样，在对象置 null 后观察内存回落趋势（非单次调用后立即比对）
- ReferenceQueue：配合 WeakReference 或 PhantomReference 使用，对象被回收时会自动入队——这是唯一能确认“某个具体对象已被回收”的方式
哪些场景下它可能“看似有用”，但需极度谨慎
这些不是推荐用法，而是说明其有限边界：
- 单元测试中配合 WeakReference 验证对象可达性状态
- 批处理任务中，某一大块临时数据（如 50MB byte[]）刚被置 null，后续一段长时间无新对象分配，可尝试提示 JVM 回收
- JDK NIO 中堆外内存分配失败（如 FileChannel.map 或 allocateDirect 抛 OOM）时，作为兜底重试机制——但这依赖 Cleaner 内部实现，不具备通用性
