System.gc()仅是向JVM发出无承诺的轻量级回收建议，不保证响应、时机或类型；现代JDK（如17+ G1/ZGC）常忽略它，真正释放内存依赖对象不可达和自动GC机制。
System.gc() 不是触发垃圾回收的开关，而是一次无承诺的提醒。它对现代 JVM（如 JDK 17+ 默认 G1 或 ZGC）基本无效，既不决定是否回收、也不控制回收时机或类型。开发者若在代码中看到它，更应质疑对象生命周期设计，而非琢磨“怎么让它起作用”。
它到底做了什么
调用 System.gc() 等价于向 JVM 发出一个轻量级信号：“当前可能是回收内存的好时机”。但 JVM 可能：
- 正在执行密集计算，选择忽略
- 刚完成一次 GC，堆内存尚充裕，暂不响应
- 启用 -XX:+DisableExplicitGC（不少云厂商 JDK 默认开启），直接当作空操作（NOP）
- 即使响应，也只可能调度一次低优先级的混合回收，而非 Full GC
为什么你常“看不到效果”
不是调用方式错了，而是观测逻辑有偏差：
- 调用后立刻查 Runtime.getRuntime().freeMemory()，往往数值不变——GC 是异步的，内存释放不即时反映
- 用 Thread.sleep(1000) 等待，毫无意义——GC 不同步阻塞当前线程
- 依赖日志却没加 -XX:+PrintGCDetails，等于闭眼判断是否真发生了回收
- 在 G1/ZGC 下观察到 FGC 次数未增，不是 bug，是设计使然：它们压根不把该调用当指令
哪些场景下它曾“看似有用”
这些属于历史遗留或边界特例，不可复用，也不代表推荐：
- JDK NIO 中 DirectByteBuffer 分配失败时，catch 到 OOM 后调用 System.gc()，是为促使 Cleaner 回收关联的 native 内存，再重试分配——本质是兜底重试，非通用策略
- 老旧环境（如 JDK 6 + Serial GC）的嵌入式设备中，资源极度受限且无自适应调度，偶有响应
- 单元测试里配合 WeakReference + ReferenceQueue，验证某对象是否已进入回收队列——仅用于观测，不用于生产逻辑
比 System.gc() 更实在的做法
真正释放内存，靠的是让对象不可达，而不是人工催促：
- 大集合及时 remove() 或 clear()，静态缓存加淘汰策略（LRU/SoftReference）
- 流、连接、NIO Buffer 必须显式 close() 或 clean()，它们的内存不在堆上，System.gc() 完全无效
- 避免 Activity/Context 长期被 static Map 持有，这类引用泄漏才是内存居高不下的主因
- 用 jstat -gc <pid> 或 MemoryMXBean 监控实际 GC 行为，而不是靠调用来“假装掌控”
