容器化Spring应用在Kubernetes集群中内存突增触发OOMKiller问题排查

1. 是否属于JVM/Spring问题或内存泄漏？类似经验分享 #

首先可以明确：这不太可能是普通业务代码导致的内存泄漏——内存泄漏的典型表现是内存随时间逐步增长，而你的场景是正常负载下突发暴涨，且多个无关联服务出现相同现象，重启后即可恢复正常，更符合框架或底层运行时的异常特征。

可能的方向及实操经验：

• JVM堆外内存未限制：如果服务依赖Netty（比如WebFlux、Kafka/ES客户端），这类组件大量使用DirectMemory（堆外内存），默认情况下JVM不会限制DirectMemory的大小（依赖系统可用内存）。当业务触发这类组件的批量操作时，DirectMemory会快速占用内存，触发Kubernetes OOM。这类问题可通过设置-XX:MaxDirectMemorySize参数限制堆外内存大小缓解。
• Spring框架隐性操作：部分Spring Boot自动配置的组件可能在特定场景下突发占用内存，比如：
  • Spring Cloud服务发现组件（如Eureka、Nacos）的全量服务拉取操作，当集群服务数量较多时，一次性加载大量服务元数据会导致内存突增；
  • Spring Cache的缓存预热/批量加载逻辑，若缓存key集合过大，会一次性申请大量内存；
• Java 11特定版本JVM Bug：部分OpenJDK 11早期版本存在JIT编译、GC相关的内存异常问题，即使是最新镜像，也建议确认具体版本（执行java -version），排查是否存在已知的内存突增Bug；
• Kubernetes节点资源波动：未设置Pod资源限制时，节点内存被耗尽会导致JVM内存分配异常；即使设置了限制，若节点存在内存碎片化或其他Pod的资源抢占，也可能触发JVM内存分配突发增长。

2. Pod被终止前获取内存快照的工具/方法 #

JVM内置参数配置 #

直接在JVM启动参数中添加：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heap-dump.hprof

同时为Pod挂载emptyDir到/tmp目录，当JVM触发OOM时会自动生成堆转储文件。Pod被终止前，可通过以下命令将文件拷贝到本地：

kubectl cp <pod-name>:/tmp/heap-dump.hprof ./local-dump.hprof

自定义监控脚本+触发Dump #

在Pod启动脚本中加入内存监控逻辑，当内存使用率达到阈值（比如80%）时自动执行堆转储：

1. 编写shell脚本（memory-monitor.sh）：

#!/bin/bash
PID=$(pgrep java)
while true; do
    MEM_USAGE=$(jstat -gc $PID | awk 'NR==3 {print ($3+$4+$6+$8)/$2*100}')
    if (( $(echo "$MEM_USAGE > 80" | bc -l) )); then
        jmap -dump:format=b,file=/tmp/heap-dump-pre-oom.hprof $PID
        break
    fi
    sleep 10
done

2. 在Dockerfile中添加该脚本，并用supervisord或nohup与Java进程并行启动。

Kubernetes临时调试容器 #

当观察到Pod内存持续上涨时，立即使用kubectl debug创建临时调试容器，进入Pod执行堆转储：

kubectl debug -it <pod-name> --image=openjdk:11 --share-processes -- bash

在调试容器中找到Java进程PID，执行：

jmap -dump:format=b,file=/tmp/debug-dump.hprof <pid>

再通过kubectl cp将文件拷贝到本地。

基于Prometheus的告警触发Dump #

通过Prometheus监控Pod内存使用率，配置Alertmanager在内存达到阈值时触发自定义Webhook，调用Pod内的脚本执行堆转储。这种方式适合自动捕获偶发的OOM场景。

内容的提问来源于stack exchange，提问作者Artique