Tomcat 服务崩溃的常见诱因与排查指南

1. 从一次深夜告警说起：Tomcat为什么突然“躺平”了？

那天凌晨两点，手机突然开始疯狂震动。我迷迷糊糊抓起来一看，监控系统发来一连串告警：线上一个核心服务的Tomcat实例，CPU使用率瞬间飙到100%，紧接着服务完全无响应，最后进程直接消失了。相信不少负责后端服务的同学都经历过这种“惊心动魄”的时刻。Tomcat作为Java Web应用最经典的“坐骑”，承载着无数业务流量，它一旦“罢工”，轻则页面打不开，重则引发线上事故。很多人第一反应是“重启试试”，这招有时确实管用，但更多时候是治标不治本，过不了多久又会复发。

所以，我们得搞清楚，这个看起来敦实可靠的“老伙计”，到底会因为哪些原因突然“撂挑子”？我结合自己这些年踩过的坑，把它崩溃的诱因归为两大类：“内忧”和“外患”。“内忧”指的是运行在Tomcat容器内部的应用程序自身的问题，比如代码写崩了、内存泄漏了、线程死锁了。“外患”则是指Tomcat运行所依赖的外部环境出了问题，比如服务器资源被榨干、端口被抢、配置文件写错了。很多时候，问题还是内外夹击，混合出现的。接下来的内容，我就带你像侦探破案一样，系统性地梳理这些常见诱因，并给你一套拿来即用的排查“组合拳”。无论你是刚接手运维的新手，还是想深化问题排查能力的老兵，这篇指南都能让你在下次面对Tomcat崩溃时，心里更有底。

2. 揪出“内忧”：应用程序自身的典型问题

Tomcat本身是一个非常稳定的Servlet容器，绝大多数时候，它的“崩溃”其实是替它肚子里运行的Web应用“背了锅”。应用程序的bug、不合理的资源使用，最终都会反映到Tomcat这个载体上。所以，排查的第一步，往往是向内看。

2.1 内存泄漏与溢出：最常见的“内存杀手”

这是我遇到最多的一类问题。JVM的内存就像一个大水池，应用程序不断创建对象就是在往里面注水，而垃圾回收（GC）则是池底的排水口。如果因为代码问题，导致有些对象明明不再使用了，却无法被GC回收（即内存泄漏），水池的水位就会不断上涨。终有一天，当程序申请新内存时，会发现整个池子（堆内存）都满了，于是JVM就会抛出著名的 java.lang.OutOfMemoryError，俗称OOM。Tomcat进程会因此直接终止。

怎么判断是内存问题？ 最直接的证据就是查看Tomcat的启动日志（catalina.out 或 localhost.log）或者系统的 dmesg 日志，里面通常会明确记录OOM错误。你也可以在JVM启动参数里加上 -XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath=/path/to/dump.hprof，这样在发生OOM的瞬间，JVM会自动把当时的内存快照（Heap Dump）保存下来。这个文件是后续分析的“案发现场”记录。

排查与解决思路：

1. 分析Heap Dump：使用专业的工具（如Eclipse MAT, VisualVM）加载这个 .hprof 文件。工具能帮你直观地看到，是哪个类的哪个对象实例数量最多、占用了最大的内存。我常用MAT的“Leak Suspects Report”功能，它能自动分析并给出疑似内存泄漏的线索。
2. 审查代码：根据工具提示，重点检查那些长期存活的对象（如静态集合类、缓存）、数据库连接、文件流等资源是否正确关闭。一个经典的错误就是在Servlet的成员变量里不断添加数据，或者用HashMap做缓存却从不清理。
3. 调整JVM参数：在彻底修复代码前，可以临时扩容“水池”。通过Tomcat的启动脚本（如catalina.sh或setenv.sh）调整 -Xms（初始堆大小）和 -Xmx（最大堆大小）。例如：JAVA_OPTS="$JAVA_OPTS -Xms2g -Xmx4g"。但这只是权