养兔子的猴的博客

OOM异常排查

OOM异常排查全流程指南

一、OOM异常分类与特征

1.1 常见OOM类型

异常类型触发条件典型场景
java.lang.OutOfMemoryError: Java heap space堆内存耗尽大对象创建/内存泄漏
java.lang.OutOfMemoryError: PermGen space永久代内存不足（JDK7及之前）类加载过多/常量池膨胀
java.lang.OutOfMemoryError: Metaspace元空间内存不足（JDK8+）动态生成类/注解处理器滥用
java.lang.OutOfMemoryError: GC Overhead Limit ExceededGC时间过长且回收效率低频繁Full GC/内存碎片严重
java.lang.OutOfMemoryError: unable to create new native thread线程数超过系统限制高并发线程创建

1.2 关键日志特征

# 堆内存溢出示例
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3332)
    at java.util.Arrays.copyOf(Arrays.java:3332)

# 元空间溢出示例
Caused by: java.lang.OutOfMemoryError: Metaspace
    at java.lang.ClassLoader.defineClass1(Native Method)

二、排查流程与工具

2.1 初步定位（5分钟）

# 1. 查看JVM内存分布
jmap -heap <PID> | grep -E 'used|committed'

# 2. 实时监控内存变化
jstat -gcutil <PID> 1000 5

# 3. 检查线程数与文件句柄
ps -eLf | grep <PID> | wc -l
ls /proc/<PID>/fd | wc -l

2.2 深度分析（30分钟）

2.2.1 堆转储生成

# 自动生成堆转储（需提前配置参数）
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdump.hprof

# 手动生成堆转储
jmap -dump:live,format=b,file=heap.hprof <PID>

2.2.2 内存分析工具对比

工具优势适用场景
Eclipse MAT离线分析/大堆支持复杂内存泄漏分析
VisualVM实时监控/堆转储可视化快速定位大对象
JProfiler线程分析/方法级调用追踪性能瓶颈定位
YourKit低开销/自动化报告生成生产环境持续监控

2.2.3 MAT分析关键步骤

  1. Histogram视图：按内存占用排序对象类型
  2. Dominator Tree：识别支配大对象
  3. Leak Suspects：自动生成泄漏报告
  4. Path to GC Roots：追踪对象引用链

2.3 典型问题定位

2.3.1 堆内存溢出

// 代码示例：无限创建对象
List<byte[]> list = new ArrayList<>();
while(true){
    list.add(new byte[1024*1024]); // 每次添加1MB数据
}

排查要点：

  • 检查缓存未释放（如Guava Cache未设置过期策略）
  • 验证集合类使用（避免ArrayList无限扩容）

2.3.2 元空间溢出

// 代码示例：动态生成类
public class DynamicClassGenerator {
    public static void main(String[] args) throws Exception {
        for(int i=0; i<100000; i++){
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(Object.class);
            enhancer.setCallback(new MethodInterceptor(){});
            enhancer.create();
        }
    }
}

排查要点：

  • 检查CGLib/ASM等字节码操作库的使用
  • 验证注解处理器是否重复生成类

三、解决方案与优化

3.1 JVM参数调优

# 堆内存调优（64位JVM）
-Xms4g -Xmx4g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

# GC策略选择
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=45

# 线程栈调优
-Xss512k -XX:ThreadStackSize=512

3.2 代码级优化

3.2.1 对象生命周期管理

// 使用try-with-resources自动关闭资源
try (InputStream is = new FileInputStream("data.bin")){
    // 业务处理
}

// 对象池化复用
GenericObjectPool<Connection> pool = new GenericObjectPool<>(new ConnectionFactory());
Connection conn = pool.borrowObject();
// 使用后归还
pool.returnObject(conn);

3.2.2 缓存策略优化

// 使用WeakHashMap实现自动清理
Map<Key, WeakReference<Value>> cache = new WeakHashMap<>();

// 设置缓存淘汰策略
Cache<String, String> cache = CacheBuilder.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .build();

3.3 系统级优化

# Linux内核参数调优
echo 100000 > /proc/sys/kernel/pid_max  # 增大最大进程数
sysctl -w vm.max_map_count=250000      # 增大文件映射数

# 内存分配策略优化
echo never > /sys/kernel/mm/transparent_hugepage/enabled

四、预防措施

4.1 监控体系搭建

# Prometheus监控配置示例
metrics:
  - name: jvm_memory_used
    query: sum(container_memory_usage_bytes{container="java-app"}) by (pod)
    alert: value > 80%

4.2 自动化防护

// 内存保护熔断
public class MemoryGuard {
    private static final long THRESHOLD = 80_000_000_000L; // 80GB
    
    public static void checkMemory() {
        Runtime runtime = Runtime.getRuntime();
        long used = runtime.totalMemory() - runtime.freeMemory();
        if(used > THRESHOLD) {
            throw new MemoryThresholdExceededException();
        }
    }
}

4.3 容量规划公式

堆内存 = (对象数 × 对象大小) × 1.5
容器内存 = JVM堆内存 × 2.5

五、典型案例分析

5.1 案例1：缓存未释放导致堆溢出

现象：电商系统大促期间频繁OOM
排查过程：

  1. 通过jmap -histo:live发现ProductDTO实例超1000万
  2. MAT分析显示缓存未清理
  3. 代码审查发现@Cacheable未配置过期时间

解决方案：

@Cacheable(value = "productCache", unless = "#result==null", 
           cacheManager = "cacheManager", 
           key = "#id", 
           sync = true,
           cacheResolver = "#root.target.dynamicCacheResolver")
public ProductDTO getProductById(Long id) {
    // 数据库查询
}

5.2 案例2：JNI调用导致本地内存泄漏

现象：音视频处理服务OOM
排查过程：

  1. pmap -x <PID>发现/dev/shm占用异常
  2. GDB调试发现未释放的AVFrame指针
  3. JNI代码审查发现NewDirectByteBuffer未释放

解决方案：

// JNI代码修正
JNIEXPORT jobject JNICALL
Java_com_example_MediaProcessor_process(JNIEnv *env, jobject thiz, jbyteArray data) {
    AVFrame *frame = av_frame_alloc();
    jobject buffer = env->NewDirectByteBuffer(frame->data[0], frame->linesize[0]);
    // 业务处理
    av_frame_free(&frame);  // 关键修复点
    return buffer;
}

六、工具链集成方案

graph TD
    A[异常发生] --> B{日志分析}
    B -->|堆内存溢出| C[生成堆转储]
    B -->|线程溢出| D[线程Dump]
    C --> E[MAT分析]
    D --> F[线程状态分析]
    E --> G[定位泄漏对象]
    F --> H[检查线程创建逻辑]
    G --> I[代码修复]
    H --> I
    I --> J[验证修复]

通过上述流程，可系统化解决90%以上的OOM问题。建议生产环境结合APM工具（如SkyWalking）和日志分析平台（如ELK）实现自动化监控，关键业务场景建议预留20%-30%的内存缓冲。

site logo

Hi,Friend

© 2026 养兔子的猴的博客