Java应用OOM问题排查

通过异常日志精确定位OOM来源

这是最准确、最直接的定位方法。当发生OOM时，JVM通常会在日志中输出具体的异常信息，通过这些信息可以直接确定是哪个内存区域出现问题。

步骤1：确定日志位置

根据不同的部署方式，OOM日志可能出现在以下位置：

• 物理机/虚拟机部署：

  • 应用日志文件：/path/to/app/logs/app.log、server.log等。

  • 标准输出/错误：nohup.out、控制台输出。

  • 系统日志：/var/log/messages（查看是否被系统OOM Killer杀死）。

• 容器/K8s部署：

  # 查看当前容器日志
  kubectl logs <pod-name> -c <container-name>
    
  # 如果Pod已重启，查看上一次的日志
  kubectl logs <pod-name> -c <container-name> --previous
    
  # Docker环境
  docker logs <container-id>

步骤2：搜索OOM相关日志

# 在日志文件中搜索OutOfMemoryError
grep -i "OutOfMemoryError" /path/to/logs/*.log

# 搜索StackOverflowError
grep -i "StackOverflowError" /path/to/logs/*.log

# 如果日志被压缩
zgrep -i "OutOfMemoryError" /path/to/logs/*.log.gz

# 查看系统是否杀死了Java进程
dmesg | grep -i "killed process"
grep -i "java" /var/log/messages | grep -i "killed"

通过应用监控定位（日志不全时的补充手段）

当无法获取到完整的OOM异常日志时（如日志被覆盖、进程突然消失等），可以通过应用监控来分析各内存区域的使用趋势，推断可能的OOM来源。

堆内存配置不足

# 查看当前JVM参数
ps -ef | grep java | grep -E "Xmx|Xms"

# 查看机器/容器资源
free -h  # 物理机
kubectl describe pod <pod-name>  # K8s环境

内存使用不合理（代码问题）

典型特征

• 业务流量基本稳定，但OOM越来越频繁。

• 老年代使用量单调递增。

• Full GC后的内存"谷底"越来越高。

• 重启后又重复相同的增长模式。

排查步骤

步骤1：创建内存快照

开启OOM时自动生成堆转储：

# 在JVM启动参数中添加，容器环境需要对/tmp/目录做持久化，避免pod重启导致快照数据丢失
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap.hprof

或者可以在内存高水位时通过内存快照白屏或者以下命令黑屏生成堆转储：

# 当ARMS显示堆使用率超过80%时执行
jmap -dump:format=b,file=/tmp/heap.hprof <pid>

步骤2：堆转储文件分析

使用应用诊断分析平台ATP或Eclipse MAT分析堆转储文件：

1. 查看内存占用Top N的对象类型

   • 关注占用内存最多的类（通常是集合类、缓存类、业务对象等）。

   • 分析这些对象是否合理。

2. 分析对象引用链

   • 查看大对象被谁持有（GC Roots路径分析）。

   • 确认是否应该被回收但被意外持有。