不会，openjdk 中 system.gc() 仅是可被忽略的提示，不阻塞、不等待、不保证回收；zgc/shenandoah 直接无视，启用 -xx:+disableexplicitgc 则为 nop，所谓“回收”多为巧合或本就触发的自动 gc。
不会，OpenJDK 调用 System.gc() 一定不会立即回收。 它只是向 JVM 发出一个可被忽略的提示，不阻塞、不等待、不保证任何回收行为发生。
OpenJDK 中 System.gc() 的实际行为
在 OpenJDK（如 17/21/23，默认 G1 或 ZGC）中，该调用已被深度弱化：
-
System.gc()底层调用的是CollectedHeap::collect(GCCause::_java_lang_system_gc)，但 JVM 不做同步等待，方法立刻返回 - G1 默认将其映射为 Full GC 请求，但需排队等安全点；若启用
-XX:+ExplicitGCInvokesConcurrent，则转为并发模式（仅限老年代） - ZGC 和 Shenandoah 完全无视该调用——既不触发 STW，也不启动任何标记周期，调用后直接返回
- 若 JVM 启动时加了
-XX:+DisableExplicitGC（Kubernetes 环境常见），System.gc()就是 NOP，连日志都不会输出
为什么“看起来回收了”不是它干的
你观察到调用后发生了 GC，大概率是巧合，而非因果：
- Eden 区刚好填满，本就会触发 Minor GC，和
System.gc()无关 - 对象仍被强引用持有（比如
static Map缓存、未remove()的ThreadLocal、未关闭的FileInputStream），即使调用一千次也无效 - 依赖
Runtime.getRuntime().freeMemory()或finalize()输出判断是否回收——这些值不实时、不可靠、且finalize()已被弃用
OpenJDK 下调用 System.gc() 的真实风险
它不是“没用”，而是“有害且不可控”：
- HotSpot 默认策略下，它常触发 Full GC，导致秒级 Stop-The-World：HTTP 接口超时、连接池耗尽、定时任务卡死
- 打乱 G1 的预测模型——比如本该延迟的老年代回收被强制提前，后续反而更频繁地 fallback 到 Full GC
- 掩盖内存泄漏：静态集合持续 add、流未 close、监听器未注销，问题被 GC 表象掩盖，直到某次压测彻底 OOM
- 容器环境（如 Docker + Kubernetes）中，JVM 检测到
memory.limit_in_bytes后，会主动跳过显式请求，使调用完全失效
真正影响回收时机的，从来不是 System.gc() 是否被调用，而是对象是否真的不可达——这取决于你有没有及时切断引用链、有没有用 try-with-resources、有没有给缓存设上限。JVM 从不撒谎，但它也不会为你背锅。
