JVM垃圾回收既是资源消耗者也是资源守护者，它通过自动内存管理防止内存泄漏和OOM，同时其开销可通过选择合适GC策略、合理配置参数及优化代码习惯来可控降低。
JVM 垃圾回收（GC）本身是资源消耗者，也是资源守护者——它占用 CPU、内存和线程时间，但同时防止更严重的资源失控，比如内存泄漏导致的 OOM 或持续增长的堆外压力。关键不在于“要不要 GC”，而在于“如何让 GC 的开销可控、可预期、可优化”。
GC 自身带来的直接资源开销
每次 GC 都不是免费的：
- CPU 占用：标记、扫描、复制或整理对象都需要计算资源。尤其在并发标记阶段（如 G1 或 ZGC），GC 线程与应用线程争抢 CPU；Stop-the-World（STW）阶段虽短，但会冻结所有 Java 线程，影响响应延迟。
- 内存额外占用：比如 G1 需要 Remembered Sets 记录跨 Region 引用，ZGC 使用着色指针和读屏障元数据，这些结构本身吃内存；Survivor 区按比例预留（如 SurvivorRatio=8 时占新生代 1/10），也是“闲置但必需”的空间成本。
- 线程与调度开销：并行 GC 启动多个 GC 工作线程，增加上下文切换；CMS 和 G1 的并发阶段依赖 JVM 内部协调机制，带来额外同步负担。
GC 如何间接降低整体系统资源消耗
没有 GC，代价更高：
- 避免内存泄漏累积：未释放的缓存、静态集合、监听器等若长期持有对象引用，会持续侵占堆内存，最终触发频繁 Full GC 甚至 OOM——此时不仅 GC 更重，还可能拖垮整个服务节点。
- 减少显式资源管理错误：不用手动 free 或 close 对象，就规避了因忘记释放、重复释放或异常路径遗漏导致的本地资源（文件句柄、Socket、Direct Buffer）耗尽，这类问题常比堆内存更难排查。
- 支撑高效资源复用机制：GC 让对象生命周期天然短暂，配合对象池（如 HikariCP 连接池、Netty 的 ByteBuf 池）能安全复用实例；若对象长期存活且不可控，池化反而加剧内存碎片和 GC 压力。
不同 GC 策略对资源平衡的影响
没有“零开销”的 GC，只有“适合场景”的权衡：
- 吞吐量优先（Parallel GC）：多线程并行回收，STW 时间较长但总耗时短，适合批处理类后台任务——CPU 利用率高，延迟容忍度高。
- 低延迟优先（G1 / ZGC / Shenandoah）：通过并发标记、增量回收、有色指针等技术压缩 STW 时间（ZGC 可控在 10ms 内），但需更多 CPU 和内存元数据开销，适合响应敏感型服务。
- 小堆轻量场景（Serial GC）：单线程、无并发开销，适合嵌入式或开发测试环境，但堆稍大即卡顿明显。
真正影响资源效率的往往是配置与代码习惯
GC 表现好坏，80% 取决于是否匹配实际负载：
- 堆大小失配：-Xms 与 -Xmx 差距过大，导致运行期反复扩容缩容，触发额外 GC；堆设得过大（如 32GB+）又可能让 G1 落入“大堆陷阱”，Region 粒度失效，退化为全局扫描。
- 对象生命周期错配：大量本该短期存在的对象（如 DTO、临时集合）因被长生命周期对象意外引用，提前晋升到老年代，加剧老年代 GC 频率。
- 不合理的引用类型：滥用 强引用 缓存大对象，或误用 SoftReference 在内存充足时仍被回收，都会破坏 GC 的自然节奏。
