Tomcat 8.5内存占用过高排查：Spring MVC应用内存持续飙升

核心结论：内存泄漏（Memory Leak） #

Tomcat 8.5上的Spring MVC应用内存持续增长、重启后恢复的表现，明确是内存泄漏问题。对比Tomcat 9的Spring Boot应用正常的情况，可排除服务器硬件、JDK全局配置等共性问题，重点聚焦在Spring MVC应用本身或Tomcat 8.5的特定配置/版本缺陷上。

可能的泄漏原因 #

• 应用层资源未释放
  • IO流、数据库连接、Redis连接、HTTP客户端连接等资源未在finally块或通过try-with-resources语法关闭，导致资源句柄堆积；
  • 第三方依赖存在泄漏bug，比如老旧版本的MyBatis映射器缓存未清理、Jackson的ObjectMapper重复创建导致对象累积；
  • 本地缓存（如HashMap、Guava Cache）未设置过期时间或最大容量，缓存大对象无限累积；Spring Cache配置错误，缓存对象未失效。
• Tomcat 8.5特定问题
  • 线程池配置不合理：maxThreads过大或keepAliveTime过长，请求处理中持有的大对象在线程存活期间无法被GC回收；
  • 版本缺陷：Tomcat 8.5早期版本（8.5.0-8.5.30区间）存在类加载器未正确卸载、JNDI资源泄漏等已知问题；
  • JVM参数配置不当：-Xmx设置过大导致GC触发阈值过高，内存缓慢累积到临界值才触发回收；未配置堆转储参数，无法定位泄漏点。
• 类加载器泄漏
  开启热部署时，旧Web应用类加载器未被GC回收，导致加载的类、静态对象堆积；自定义ThreadLocal未清理，线程池线程持有旧类加载器引用，内存无法释放。

具体排查步骤 #

1. 生成并分析堆转储文件
   • 给Tomcat 8.5添加JVM参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/tomcat/dumps，或在内存增长至100G以上时，用命令手动生成：jmap -dump:format=b,file=heapdump.hprof <tomcat_pid>；
   • 用MAT（Memory Analyzer Tool）打开堆转储，查看支配树，定位占用内存最大的对象集合，关联到具体代码类。
2. 分析GC日志
   • 添加GC日志参数：-Xloggc:/opt/tomcat/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC，观察GC频率、回收内存量，判断是年轻代还是老年代内存无法回收。
3. 检查线程与连接池
   • 用jstack <tomcat_pid>查看线程状态，排查是否有大量阻塞线程持有大对象；
   • 查看数据库连接池（如Druid、HikariCP）监控，确认是否有连接未释放、连接池耗尽的情况；
   • 通过Tomcat Manager或jconsole查看线程池状态，检查线程是否长期存活且持有资源。
4. 升级Tomcat版本
   将Tomcat 8.5升级到最新稳定版（如8.5.99），验证是否为版本固有泄漏问题。

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