服务器oom崩溃的核心是物理内存+swap耗尽触发oom killer杀进程，必须分三步：先用dmesg/grep/oom日志和free -h确认是否oom；再用top/ps/jstat定位高内存进程及java gc异常；最后按堆不足、内存泄漏、大对象加载、元空间或直接内存溢出分类修复，并通过heapdump、监控告警和代码规范防复发。
服务器因内存溢出（OOM）崩溃，核心是系统物理内存 + Swap 耗尽后触发内核 OOM Killer 强制杀进程。这不是简单“加内存”就能解决的问题，必须分三步走：先确认是不是 OOM、再定位谁在吃内存、最后针对性修复。
第一步：确认确实是 OOM 导致崩溃
别猜，用命令直接验证：
- dmesg | grep -i "out of memory" —— 查内核日志，看到类似 "Out of memory: Kill process 1234 (java)" 就是铁证
- grep -i oom /var/log/messages（CentOS/RHEL）或 /var/log/syslog（Ubuntu/Debian）—— 看触发时间、被杀进程名、当时内存状态
- free -h —— 关键看：used 接近 total 且 swap 已基本占满，基本可锁定为内存资源见底
第二步：快速定位高内存消耗源
重启后内存可能已回落，但要抓“活口”就得趁早：
- top 或 htop —— 按 M 键按内存使用排序，一眼看出哪个进程（java、php-fpm、node、mysql）占最多
- ps aux --sort=-%mem | head -10 —— 列出内存前10的进程，含 PID 和完整命令行，方便进一步分析
- 如果是 Java 进程，立刻执行：jstat -gc
1000 5 —— 观察是否频繁 Full GC、老年代持续增长，这是堆泄漏典型信号 - 必要时导出堆快照：jmap -dump:format=b,file=/tmp/heap.hprof
（需有权限），后续用 MAT 或 VisualVM 分析
第三步：按原因分类解决
不能只调大 -Xmx，得对症下药：
- 堆内存不足（Java heap space）：检查是否真缺内存。若业务流量翻倍但 JVM 堆没扩容，可适当调大 -Xmx；但若调大后仍 OOM，大概率是泄漏，不是配置问题
- 内存泄漏：用 MAT 打开 heap.hprof → “Leak Suspects” 报告 → 看 dominated heap 最大的类 → 追溯 GC Roots 引用链。常见坑：静态集合缓存未清理、监听器未注销、流/连接未 close、线程局部变量（ThreadLocal）持有对象不释放
- 大对象/数据加载失控：比如一次查 100 万行数据库结果集、读取超大文件到 byte[]、生成巨量临时对象。改成分页查询、流式处理、对象复用或限制单次处理量
- 元空间（Metaspace）溢出：JDK8+ 常见，多因动态生成类（如 Spring CGLIB、Groovy 脚本、热部署）。加参数 -XX:MaxMetaspaceSize=512m 并监控，同时排查类加载器是否泄漏
- 本地内存（Direct Memory）溢出：NIO 使用 DirectByteBuffer 时易发，尤其 Netty、RocketMQ 场景。加 -XX:MaxDirectMemorySize=1g，并检查是否反复 allocate 未 clean
长期防复发关键动作
光救火不行，得建防线：
- 上线前强制配置：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/oom/，确保每次 OOM 都留证据
- 用 Prometheus + Grafana 监控 JVM 各区内存、GC 时间、线程数、Metaspace 使用率，设阈值告警（如老年代 >90% 持续 5 分钟）
- 定期做压力测试，模拟峰值流量，观察内存增长趋势和 GC 行为，不等到上线才暴露
- 代码评审加入内存安全项：禁止无上限集合 add、检查 try-with-resources、避免 static 持有业务对象、缓存必须设大小和过期策略
