oom自愈需四步闭环：一、jvm感知容器内存边界并校验；二、rss达85%时主动降级（gc切换、功能关闭、请求路由降级）；三、通过cgroup+prometheus捕获oom事件，30秒内隔离pod；四、压测验证、自动回滚、全链路审计归档。
遇到内存溢出（OOM）时，不能只靠Kubernetes杀Pod了事——那不是自愈，是“自毁”。真正优雅的微服务自愈，是在OOM发生前感知风险、在临界点主动降级、在崩溃后快速隔离并恢复，全程不中断核心业务流。
一、提前感知：让JVM“看见”容器的真实内存边界
很多OOM源于JVM对容器内存限制“视而不见”。即使使用JDK 8u131+，仍需确认以下三点：
- UseContainerSupport必须启用（新版默认开启，但旧镜像或定制JVM可能关闭）；
-
堆外内存（Direct Memory、Metaspace、线程栈）必须显式限制，例如：
-XX:MaxDirectMemorySize=256m -XX:MaxMetaspaceSize=512m -Xss256k； -
避免用
-Xmx硬设为节点总内存的固定比例（如“-Xmx4g”），应结合Cgroups实际限制动态计算——可通过/sys/fs/cgroup/memory.max读取，并在启动脚本中生成适配的JVM参数。
推荐在应用启动时打印Runtime.getRuntime().maxMemory()和ProcMemInfo读取的cgroup memory limit，做一致性校验。不匹配就拒绝启动，防患于未然。
二、临界干预：基于资源感知的优雅降级
当RSS接近cgroup memory limit（比如达85%）时，不应等OOM Killer出手，而应由应用主动收缩：
- 触发轻量级GC策略切换（如从G1切换至ZGC，或调小G1HeapRegionSize）；
- 关闭非关键功能模块，如实时日志采样率降至1%、熔断指标上报、暂停异步缓存预热；
- 将部分请求路由至“降级模式”：返回缓存快照、简化响应体、跳过复杂计算链路。
这些动作需通过健康检查端点（/actuator/health或自定义/health/ext）暴露状态，让Service Mesh或Ingress网关识别并分流，实现“故障不扩散、体验不崩塌”。
三、崩溃隔离：精准捕获OOM事件并自动切流
Kubernetes无法区分“应用主动退出”和“被OOM Killer杀死”。要实现精准隔离，需两层联动：
-
容器层：在Docker/Kata配置
oom_kill_disable=false，确保OOM事件可被cgroup v2的memory.events捕获；配合轻量代理（如cgroup-exporter）将oom_kill计数推送至Prometheus； -
编排层：用Prometheus Alertmanager监听
container_oom_kills_total > 0，触发Kubernetes Job执行隔离脚本——该脚本会标记Pod为oom-isolated=true，并通过NetworkPolicy禁止其对外通信，同时调用服务注册中心下线其实例。
整个过程可在30秒内完成，比等待Readiness Probe失败再驱逐快一个数量级。
四、恢复闭环：修复验证 + 状态归档
自愈不止于重启。一次OOM后必须验证是否根除隐患：
- 新Pod启动后，自动运行内存压测Job（如JMeter短时高并发请求），监控RSS增长斜率与GC频率；
- 若10分钟内RSS再次逼近limit，自动回滚至前一稳定镜像版本，并告警“内存泄漏疑似复现”；
- 所有OOM事件关联traceID、cgroup配置、JVM参数快照，写入审计日志库，供后续用eBPF工具（如
bpftrace）回溯堆外分配热点。
这才是闭环——不是“修好了”，而是“知道为什么坏、怎么才算真好了”。
