看是哪种OOM?
看报错信息/监控/容器事件，区分类型，不同解法完全不一样。
Java heap
java.lang.OutOfMemoryError: Java heap space GC overhead limit exceeded（一直 GC 但回收极少）
Direct/Off-heap
java.lang.OutOfMemoryError: Direct buffer memory（NIO/Netty/ByteBuffer） 原生内存耗尽（JNA、压缩、TLS、线程栈等）
Metaspace
java.lang.OutOfMemoryError: Metaspace（类加载泄漏/频繁重载）
系统/容器把进程杀了
K8s：OOMKilled；Linux：dmesg 里 Out of memory: Kill process JVM 日志未必有 OOM 栈
判定方法：应用日志、K8s 事件 (kubectl describe pod)、系统日志 (dmesg)、JVM 日志（GC/错误日志）。
快速止血（把服务活下来）
扩容/降流/限并发：临时缩小线程池或限流；必要时扩副本。
增配但留余量：容器 memoryLimit ↑，同时Xmx 要明显小于 limit（给 off-heap/线程/代码缓存留 30% 余量）。
降级：关闭大对象功能（一次性加载、导出、聚合）、降低批量大小。
打开取证开关（见下一步），重启服务。
取证与快速体检（上线就该常备）
JVM 启动参数（长期建议）
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump（自动导出 heap dump）
- -Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags（JDK9+；JDK8 用 -Xloggc）
- （可选）-XX:NativeMemoryTracking=summary（开销小）或 detail
线上排查常用命令
- 线程/堆： jcmd <pid> GC.heap_info、jcmd <pid> GC.class_histogram jmap -histo:live <pid> | head -50（大对象分布） jmap -dump:live,format=b,file=heap.hprof <pid> jstack -l <pid>（看看是否卡某些线程/ThreadLocal 泄漏）
- 原生内存： jcmd <pid> VM.native_memory summary（NMT：看 Direct / Internal / Thread 等占用）
- 容器/系统： kubectl top pod / describe pod（OOMKilled） ps -o pid,rss,command -p <pid>、pmap -x <pid>、dmesg | tail
对症下药（不同 OOM 的根因与修复）
Heap OOM / GC Overhead
症状：堆占用持续上升或 Full GC 频繁。
定位：用 Dump 在 MAT/VisualVM 看Dominator Tree、GC Roots 路径，找最大保留集。
常见根因 & 修复
- 无限制缓存/Map（没有 TTL/最大容量）→ 上 Caffeine/GuavaSize/Weight + TTL，监控命中率与大小
- 聚合/拼装大对象（一次性 toList()、大 StringBuilder、无分页）→ 分页/分块处理，流式读写
- ThreadLocal 泄漏（未 remove）→ try/finally 清理；线程池复用时尤需注意
- 反序列化/JSON 组装大对象→ 换流式解析（Jackson streaming）、限制字段
- 序列化队列堆积（MQ/队列消费不过来）→ 限流/背压，调小批量
调参兜底：
- 合理设置Xms=Xmx（避免频繁扩容），用G1/GenZ。
- 检查 -XX:MaxRAMPercentage（容器内）与 Limit 的匹配，确保Xmx < Limit × 0.7左右。
Direct buffer / Off-heap OOM
症状：报 Direct buffer memory 或 RSS 高而堆不高。
定位：NMT（VM.native_memory summary）、应用指标（Netty PooledArena）、-XX:MaxDirectMemorySize。
根因 & 修复
- 未释放 ByteBuffer/Netty ByteBuf→ 确保 release()：用 Try-With-Resources 包装，开启 Netty 泄漏检测 -Dio.netty.leakDetectionLevel=paranoid（只在测试/预发）
- 无上限的直接内存→ 配置 -XX:MaxDirectMemorySize=256m~1g；Netty 配对象池且限制最大并发
- 大响应/压缩/SSL 原生内存→ 减小批量、分块，确认本地/Native 库版本
Metaspace OOM
症状：OutOfMemoryError: Metaspace。
根因：类加载器泄漏（反复热加载/动态代理生成类、URLClassLoader 未关闭）。
修复：
- 修正热加载逻辑；减少频繁生成新 Class。
- 调整 -XX:MaxMetaspaceSize 但重点是修复泄漏。
- jcmd <pid> VM.classloaders、GC.class_stats 辅助判断。
unable to create new native thread
症状：线程数爆表或系统 ulimit -u 限制。
修复：
- 控线程池并发、合并池；合理 queue 与拒绝策略。
- 调整容器/系统线程数限制。
- 用 jstack/top -H 找线程源头（哪个池在疯狂建线程）。
容器 OOMKilled（非 JVM 报 OOM）
症状：Pod 被杀，JVM没栈。
修复：
- JVM 堆（Xmx）+ 原生内存之和必须显著小于K8s Limit。
- JDK11+ 使用 -XX:MaxRAMPercentage（如 50）配合 Limit。
- 预留线程栈/Direct/Metaspace/CodeCache 等空间（通常 ≥ 30% 预留）。
防复发（工程化治理）
- 监控告警：堆使用率、Young/Old GC 次数与时间、Full GC、RSS、Direct 内存、线程数、类加载数、对象分配速率。
- 容量/压测：关键接口做 3× 峰值压测，观察 P95/P99 与 RSS；设置自动化内存回归测试。
- 限流与背压：线程池有界队列 + 合理拒绝策略；对外部依赖设置超时与舱壁。
- 数据/批量：所有批处理/导出/聚合都限制批大小并流式处理。
- 开关与熔断：配置化关闭大对象功能；遇压自动降级。
