必须快速响应、精准定位、最小化影响，核心是靠预设机制捕获现场、用数据驱动判断、按类型分路径处置：告警触发5分钟内摘流、查GC趋势、启用堆转储；依错误类型（heap/Metaspace/thread/Direct buffer/GC overhead）分路径排查；堆转储必看MAT的Leak Suspects、Histogram、Path to GC Roots；修复后需预发压测4小时验证并检查JVM参数合理性。
生产环境内存溢出（OOM）必须快速响应、精准定位、最小化影响。核心不是“等它崩”，而是靠预设机制捕获现场、用数据驱动判断、按类型分路径处置。
一、告警触发后立即执行的标准化动作
收到内存使用率≥90%或OOM日志告警，5分钟内完成以下操作：
- 将问题实例从负载均衡摘除，禁止新流量进入
- 确认JVM进程PID，执行jstat -gcutil <pid> 1000 3，快速查看GC频率与老年代占用趋势
- 检查是否已启用自动堆转储：运行jinfo -flag +HeapDumpOnOutOfMemoryError <pid>，若未启用，立即补加并重启（仅限非核心服务）
- 保留原始日志片段（含完整堆栈和时间戳），不覆盖、不清理任何日志文件
二、根据OOM错误类型选择排查路径
日志中明确的错误信息是第一判断依据，不同错误对应不同内存区域和根因方向：
- Java heap space → 重点查对象泄漏：静态集合、缓存无淘汰、ThreadLocal未清理、大对象堆积
- Metaspace → 重点查类加载行为：动态代理生成类过多、热部署未卸载类、Spring Boot DevTools残留
- Unable to create new native thread → 查线程数与系统限制：jstack <pid> | wc -l 对比 ulimit -u 和 -Xss 设置
- Direct buffer memory → 查NIO使用：Netty堆外内存泄漏、未调用cleaner.clean()或ByteBuffer.clear()
- GC overhead limit exceeded → 不是独立错误，是堆内存严重泄漏或碎片化的信号，需同步分析堆转储+GC日志
三、堆转储分析必须完成的三项关键动作
拿到.hprof文件后，不依赖直觉，只看三个MAT视图：
立即学习“Java免费学习笔记（深入）”；
- 打开Leak Suspects Report，直接定位前2个高概率泄漏点（如“One instance of XXX dominates 82% of heap”）
- 查看Histogram，按“Objects”倒序，找数量异常多或单个实例超大的类（如byte[]、HashMap$Node、String）
- 对可疑类右键→Path to GC Roots → with all references，确认强引用链——重点看static、ThreadLocal、ClassLoader、监听器注册点
四、验证修复与上线前的强制检查项
代码修改后，不能直接上生产：
- 在同等配置的预发环境，用相同压测流量跑满4小时，监控老年代使用率是否稳定在60%以下
- 对比修复前后jstat -gc <pid>输出，确保Full GC次数下降、每次耗时缩短、老年代回收量提升
- 检查JVM启动参数是否合理：-Xms与-Xmx设为相等（防动态扩容抖动），-XX:MaxMetaspaceSize不低于256m，-Xss不高于256k（除非明确需要大栈）
- 所有修复代码必须附带单元测试，覆盖该对象生命周期的创建→使用→释放全过程
