GC不具备自愈能力，OOM发生时JVM只能抛出异常并可能崩溃；G1通过提前触发Mixed GC分散回收压力，ZGC凭借亚毫秒停顿保障高并发下的响应性。
Java 垃圾回收器本身不具备“自愈”能力，G1 或 ZGC 都不能在发生 OOM 时自动修复问题、恢复服务或绕过内存瓶颈。所谓“面对高并发 OOM 的自愈”，是一种常见误解——实际是通过合理配置与设计，让 GC 在压力下更稳定、更可控，从而降低 OOM 概率，并为人工干预争取时间。
为什么说 GC 不会“自愈”
OOM（OutOfMemoryError）本质是 JVM 已无法满足内存分配请求，例如：
- 年轻代 Eden 区满且 Minor GC 后仍无法腾出空间创建新对象；
- 老年代/堆整体使用率达 100%，Mixed GC 或 Full GC 也无法释放足够内存；
- ZGC 虽停顿极短，但若对象分配速率持续远超回收速率（如突发流量打爆堆），仍会快速耗尽可用内存。
此时 JVM 只能抛出 java.lang.OutOfMemoryError: Java heap space 并可能终止线程或崩溃进程——GC 线程不会重启应用、扩容堆、降级功能或熔断请求。
G1/ZGC 如何“缓解”高并发下的 OOM 风险
它们的真正价值在于把不可控的雪崩，变成可观察、可预测、可干预的渐进式压力响应：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
-
G1 的 Mixed GC 主动调控：不等老年代爆满才行动，而是根据
-XX:InitiatingHeapOccupancyPercent=35提前触发混合回收，优先清理垃圾最多的 Region，把大块内存释放节奏“打散”，避免集中式 Full GC 导致长时间 STW 和请求堆积。 - ZGC 的亚毫秒停顿保障响应性：即使堆已达 12GB，ZGC 单次 GC 停顿仍稳定在
-
统一内存视图 + 可量化指标：G1 日志中的
[GC pause (G1 Evacuation Pause) (young)]、ZGC 日志里的[gc(123) Pause Mark Start]都提供精确耗时、回收量、晋升量。这些数据可接入 Prometheus，一旦发现 “单位时间 GC 次数突增 + 每次回收内存下降”，就能提前预警内存泄漏或流量异常。
真正起作用的“自愈”其实是人+机制
GC 是工具，不是守护神。生产中减少高并发 OOM 的有效动作包括：
- 用
-XX:+PrintGCDetails -Xlog:gc*开启详细 GC 日志，结合 Grafana 看 GC 频率、吞吐、平均停顿趋势； - 设置 JVM 堆上限（
-Xmx）并预留 15%~20% 内存给元空间、直接内存、线程栈，避免 OS 层 OOM； - 对高频创建的临时对象（如 JSON 解析、日志拼接），复用对象池或改用堆外缓冲（Netty ByteBuf）；
- 配合限流（Sentinel）、降级（Hystrix）、自动扩缩容（K8s HPA）形成闭环，当 GC 告警触发时，自动限制新请求流入。
GC 收集器越先进，越需要你懂它什么时候“力竭”，而不是幻想它会自己变强。
