Ubuntu Java日志中出现OOM怎么办

Ubuntu Java 日志出现 OOM 的定位与处置

一、先判断 OOM 来源

区分两类现象：
- JVM 抛出 OutOfMemoryError：日志里能看到明确的异常类型，如 Java heap space、Metaspace、Direct buffer memory、unable to create new native thread、GC overhead limit exceeded 等，这类属于 JVM 内存区域或 GC 异常。
- 内核 OOM Killer 终止进程：系统日志出现 “Out of memory: Kill process … (java) …”，这是 Linux 内核在内存紧张时按启发式评分杀掉进程，并非 JVM 主动抛出。常见于物理内存与 swap 不足、或应用申请过量内存（overcommit）。

二、快速定位步骤

确认是否触发内核 OOM Killer
- 查看系统日志：sudo grep -i "out of memory" /var/log/kern.log 或 journalctl -k | grep -i "oom"，若出现 “Kill process … (java)” 基本可判定为内核 OOM。
确认 JVM 异常类型
- 在应用日志中搜索：grep -i "OutOfMemoryError" app.log；结合异常类型决定后续分析路径（堆、元空间、直接内存、线程、GC 开销等）。
抓取现场证据（下次复现前先加上，便于定位）
- 开启堆转储与 GC 日志：
  - -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dumps/heap.hprof
  - -Xlog:gc*,gc+heap=debug:file=/data/logs/gc.log:time,tags:filecount=10,filesize=100M
- 现场命令（不重启）：
  - jps -l 查 PID
  - jstat -gc <PID> 1000 观察各区使用与 GC 行为
  - jmap -dump:format=b,file=heap.hprof <PID> 手动导出堆转储
  - jstack <PID> > threads.txt 导出线程栈
分析要点
- 堆问题用 MAT 分析 hprof，找 Dominator Tree、重复加载的 ClassLoader、泄漏引用链。
- GC 异常结合 GC 日志看是否频繁 Full GC、回收效果差。
- 线程问题结合线程栈与 ulimit -u 检查是否触及系统线程/进程数限制。

三、常见 OOM 类型与对策

错误类型	典型特征	优先检查	处理建议
Java heap space	堆分配失败	GC 日志、堆转储	排查泄漏与大对象；合理设置 -Xms/-Xmx；必要时优化数据结构/批处理
Metaspace	类加载过多	类加载数、ClassLoader 泄漏	控制动态类生成；设置 -XX:MaxMetaspaceSize；修复热部署泄漏
Direct buffer memory	NIO/Netty 直接内存不足	直接缓冲区使用、回收	释放 ByteBuffer 引用；必要时调 -XX:MaxDirectMemorySize；审视第三方库
unable to create new native thread	线程创建失败	线程数、栈大小、ulimit	使用线程池限流；减小 -Xss；提升 ulimit -u 与内核限制
GC overhead limit exceeded	GC 占时高、回收少	GC 日志	多半是堆被占满或泄漏；先定位根因，再调堆与 GC 策略
Requested array size exceeds VM limit	超大数组分配	数组长度计算	修正长度逻辑，避免接近 Integer.MAX_VALUE 的分配
CodeCache	JIT 代码缓存满	编译日志、热点方法	调大 -XX:ReservedCodeCacheSize 或优化编译策略
Out of swap space?	虚拟内存耗尽	物理内存、swap、native 内存	增加内存或 swap；排查 native/堆外泄漏；降低堆外占用
Kernel OOM Killer	内核日志杀 java	内存与 swap、overcommit	控制内存申请、加内存/扩 swap、优化负载或限流降级

说明：上表覆盖了生产最常见场景；不同 JDK 版本与 GC 策略下表现略有差异，需结合日志与现场证据综合判断。

四、系统层面的优化与注意事项

内存与 swap
- 优先保证足够的 物理内存；swap 可作为缓冲但会增加 GC 暂停时间，不建议作为长期方案。
- 如确需扩容 swap（示例，请先评估容量与性能影响）：
  - sudo swapoff -a
  - sudo dd if=/dev/zero of=/swapfile bs=1M count=8192
  - sudo mkswap /swapfile
  - sudo swapon /swapfile
防止过量承诺与限制滥用
- 检查 /proc/sys/vm/overcommit_memory 与 /proc/sys/vm/overcommit_ratio，避免应用无节制申请导致内核 OOM。
- 合理设置 ulimit -u（最大用户进程数）与容器/系统的 cgroup 内存限制，避免线程/进程数触顶。
监控与容量规划
- 建立对 RSS、堆使用、GC 停顿、线程数 的监控与告警；峰值期考虑水平扩展/限流降级。

五、最小可用的应急与根治方案

应急
- 立刻保留现场：系统日志（kern.log）、应用日志、GC 日志、线程栈、堆转储。
- 临时限流/降级，避免级联雪崩；必要时重启到安全配置（如降低并发、减小堆外占用）。
根治
- 依据错误类型执行对应修复：泄漏则修代码与引用生命周期；配置不足则合理设置 -Xmx/-Xms/-XX:MaxMetaspaceSize/-Xss；线程问题用线程池与限流；NIO/直接内存需审视资源释放与池化策略。
- 复现前务必开启 HeapDumpOnOutOfMemoryError 与 GC 日志，并使用 MAT/JFR 持续验证优化效果。

最新问答