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 -c

# 如果Pod已重启，查看上一次的日志

kubectl logs -c --previous

# Docker环境

docker logs 步骤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"异常信息对应的内存区域异常信息

内存区域

下一步排查方向

java.lang.OutOfMemoryError: Java heap space

堆内存

堆内存问题排查

java.lang.OutOfMemoryError: Metaspace

元空间

元空间（Metaspace）问题排查

java.lang.OutOfMemoryError: Direct buffer memory

直接内存

直接内存（Direct Memory）问题排查

java.lang.OutOfMemoryError: unable to create new native thread

线程栈/系统资源

其他堆外内存区域定位与排查

重要 如果能找到明确的OOM异常日志，基本可以100%确定问题区域，这比任何监控工具都要准确。