System.gc()仅是向JVM发出垃圾回收建议，不保证执行，也不影响内存分配行为；真正决定分配与回收的是JVM内存模型、GC策略及启动参数。
System.gc() 不会直接影响内存分配行为，它只向 JVM 提出一次“建议回收垃圾”的请求，对堆内对象的内存分配过程本身没有改变。真正决定内存如何分配、何时扩容、哪些区域参与回收的，是 JVM 的内存模型和 GC 策略，而不是这个调用。
它不参与内存分配流程
Java 中的对象内存分配由 JVM 在新生代（Eden 区）中完成，过程包括指针碰撞或 TLAB 分配，全程由 GC 线程与分配逻辑协同控制。System.gc() 既不触发分配动作，也不修改堆大小、不调整 Eden/Survivor 比例，更不会让下一次 new 出的对象落在不同区域。
- 分配速度、对象大小、TLAB 阈值等，均由 JVM 启动参数（如 -Xmn、-XX:TLABSize）和运行时统计决定
- 即使刚执行完 System.gc()，下一个 new Object() 还是在 Eden 区照常分配，不会跳过或绕开原有规则
- 它不改变对象的分配路径（比如不会强制大对象直接进老年代），这点和 -XX:PretenureSizeThreshold 参数有本质区别
它可能间接影响后续分配的“空间可用性”
如果 JVM 接受了该建议并实际执行了一次 Full GC（尤其是老年代被回收），那么堆中可分配的空闲内存会增多。这会让后续一段时间内的分配更少触发 GC，降低因空间不足导致的 Minor GC 频率。
- 例如：某次批量处理后堆内存使用率达 95%，此时调用 System.gc() 并成功触发 Full GC，释放出大量老年代空间 → 下一轮循环分配时 Eden 区更容易填满但老年代压力变小
- 但这种“缓解”是短暂且不可控的；若 GC 实际未执行，或只做了 Young GC，对老年代空间无影响，分配压力依然存在
- 频繁调用反而可能造成 GC 合并延迟、晋升加速，间接导致更多对象提前进入老年代，长期看恶化分配效率
它对堆外内存完全无效
DirectByteBuffer、Unsafe.allocateMemory 等分配的堆外内存（Direct Memory），不受 System.gc() 影响。这类内存由 Cleaner 机制异步释放，仅在对应堆内对象被回收且 Cleaner 执行时才可能清理——而 System.gc() 无法保证 Cleaner 立即运行。
立即学习“Java免费学习笔记（深入）”；
- 常见误区：以为调用 System.gc() 就能释放 NIO 缓冲区占用的内存 → 实际上 Direct Memory 曲线在 VisualGC 中基本不动
- 若堆外内存持续增长，应检查 ByteBuf 泄漏、未调用 clean() 或 Cleaner 未被及时触发，而非依赖 System.gc()
- 相关参数如 -XX:MaxDirectMemorySize 才是控制其分配上限的关键
它不能替代合理的内存配置与监控
把 System.gc() 当作“腾出空间”的手段，往往掩盖了真正的瓶颈。内存分配问题的根源通常在于：
- 堆初始/最大值设置不合理（-Xms 与 -Xmx 差距过大，引发动态扩容开销）
- 新生代过小（-Xmn 太低），导致对象频繁晋升、老年代快速填满
- 元空间配置缺失（-XX:MetaspaceSize 未设），类加载过多引发 Metaspace OOM
- 缺乏 GC 日志（-Xlog:gc*）和工具分析（如 GCViewer、Prometheus + jvm_exporter）
