Tomcat 内存溢出排查与优化全攻略

Tomcat OOM 问题根因分析与解决方案

Tomcat 内存溢出（OutOfMemoryError）是生产环境常见故障。本文系统梳理 JVM 内存模型、常见 OOM 类型、排查工具链及调优实战，助你快速定位解决内存问题。

JVM 内存区域与 OOM 类型

排查工具链实战

1. 命令行快速定位

# 查看进程内存使用
jstat -gcutil  1000 10

# 生成堆转储快照
jmap -dump:live,format=b,file=heap.hprof 

# 查看线程堆栈
jstack  > thread_dump.txt

2. 可视化深度分析

• MAT (Memory Analyzer Tool)：分析 heap.hprof，定位大对象、GC Roots 引用链、内存泄漏嫌疑点
• JProfiler / Arthas：在线监控内存趋势、对象创建统计、类加载情况
• GC 日志分析：开启 -Xlog:gc*:file=gc.log:time,uptime,level,tags，用 GCViewer 或 GCEasy 分析 GC 频率、耗时、内存回收效率

常见场景调优案例

案例一：堆内存溢出

现象：Full GC 频繁，老年代占用持续上升，最终 OOM

排查：MAT 分析发现 ArrayList 持有大量未释放的业务对象，代码中静态集合未清理

解决：

1. 修复内存泄漏：使用弱引用或定时清理机制
2. 调整堆参数：-Xms4g -Xmx4g -XX:NewRatio=2
3. 优化 GC：-XX:+UseG1GC -XX:MaxGCPauseMillis=200

案例二：元空间溢出

现象：重新部署应用后 Metaspace 持续增长

原因：类加载器未卸载，常见于使用 CGLIB、Spring AOP、JSP 动态编译场景

解决：

1. 设置上限：-XX:MaxMetaspaceSize=512m
2. 排查类加载器泄漏：MAT 查找 ClassLoader 实例数量
3. 减少动态代理生成频率，缓存代理类

案例三：直接内存泄漏

现象：堆内存正常，但物理内存持续上升，容器被 Kill

原因：Netty/Redis 客户端 DirectByteBuffer 未释放，或 -XX:MaxDirectMemorySize 未设置导致无限制增长

解决：

1. 显式设置上限：-XX:MaxDirectMemorySize=2g
2. 升级中间件客户端版本，修复已知泄漏 Bug
3. 使用 Cleaner 或反射手动释放 DirectBuffer

生产环境最佳实践清单

1. 基础配置：显式设置 -Xms/-Xmx，避免动态扩容；配置 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/heap.hprof
2. 监控告警：接入 Prometheus + Grafana 监控 JVM 内存、GC 指标，设置老年代使用率 > 85% 告警
3. 压测验证：上线前进行长时间压测，观察内存增长曲线，确认无泄漏
4. 代码规范：避免大对象直接入静态集合；ThreadLocal 使用后及时 remove；流式处理大文件/大结果集

总结

Tomcat OOM 本质是 JVM 内存管理问题。掌握「监控发现 → Dump 分析 → 代码定位 → 参数调优 → 验证复盘」的标准化排查流程，配合 MAT、Arthas 等利器，大多数内存问题可在小时级解决。预防胜于治疗，建立完善的监控体系与代码审查机制才是根本。