监控面板上CPU突然拉满，接口响应从几十毫秒跳到十几秒，然后进程没了，重启，恢复，过几个小时再来一次，你把catalina.out翻到底，只看到一堆堆栈和一句冷冰冰的OutOfMemoryError，Tomcat就像一个被塞了太多活的员工，倒下之前其实喊过很多次救命,只是没人听见。
先认清现场：Tomcat崩溃的六种典型死法
诊断之前先分型，不同类型的崩溃，处理手段完全相反，把现象对号入座,能省掉一半排查时间。
堆内存溢出：java.lang.OutOfMemoryError: Java heap space
最常见的一种，特征很明确：日志里出现这个错误，进程可能还活着但业务已经挂了，或者直接被容器杀掉，根因通常是对象只进不出——大查询一次性加载几十万条记录、缓存无上限增长、集合类忘记清理，据Oracle官方JDK调优文档的说法，堆溢出优先怀疑应用层持有引用，而不是先把-Xmx调大。
元空间撑爆：java.lang.OutOfMemoryError: Metaspace
多见于频繁热部署、动态生成类、大量使用反射和字节码增强框架的场景，每次重新部署war包，旧ClassLoader本该被回收，如果应用里有线程、ThreadLocal或者JDBC驱动没注销，这个ClassLoader就被钉在内存里,元空间一路涨到上限。
线程创建失败：java.lang.OutOfMemoryError: unable to create new native thread
这个报错看着像内存不够，其实是线程数或系统限制到了天花板，要么是maxThreads给得太大、请求堆积导致线程暴涨，要么是系统级ulimit -u、线程栈大小（-Xss）设得不合理。
GC开销超限：GC overhead limit exceeded
JVM在告诉你：我98%的时间都在做垃圾回收，却只回收出不到2%的空间，这活干不下去了，这是堆快满的前兆信号,比直接堆溢出更值得警惕。
进程凭空消失
没有异常日志，没有heap dump，进程说没就没，大概率是Linux的OOM Killer动的手，执行dmesg -T | grep -i "killed process"，如果看到Tomcat的PID，就基本确定了——容器内存超限,内核挑了最占内存的那个杀。
假死：端口通、请求全超时
进程还在，8080端口还在监听，但所有请求都卡住，这种往往是线程池全部被慢请求占满，或者数据库连接池耗尽,请求在排队而不是在执行。
内存类崩溃：看住堆，等于守住半条命
三步定位内存增长
- 先用
jps -l拿到PID，再执行jstat -gcutil <pid> 1000连续观察，重点看老年代使用率（O列）是否持续攀升不回落，Full GC（FGC列）次数是否在快速增加。 - 用
jmap -histo:live <pid> | head -30
看存活对象排行，排在前面的类,就是你要去代码里找的地方。
- 需要精确定位时，用
jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>导出堆快照,再配合MAT或JProfiler分析支配树。
参数要给对，也要给对位置
生产环境建议在setenv.sh里统一配置,别散落在各处：
-Xms与-Xmx设为相同值，避免堆动态伸缩带来的额外停顿，通常取物理内存的一半左右,同时给操作系统和其他进程留足空间。-XX:MetaspaceSize和-XX:MaxMetaspaceSize显式指定,不要让它无限增长。- 务必加上
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，这一次崩溃的现场，就是下一次问题的答案，dump目录要提前留够磁盘空间,见过太多因为dump写不进去导致关键证据丢失的例子。
几个高频泄漏源
- 自建的静态Map做缓存，没有淘汰策略,只增不减。
- 数据库查询没做分页,一次select出全表数据。
- ThreadLocal用完没remove,线程池复用时对象被一直持有。
- 日志框架里拼接了超大对象，或者开启了过细的debug级别,字符串在内存里堆积。
线程与连接类崩溃：不是没资源，是资源被占着不放
maxThreads给多大才合适
server.xml里的Connector配置，是很多人凭感觉拍脑袋的地方，常见写法是maxThreads="800"甚至更高，觉得数字大就能扛，实际上线程过多会让上下文切换吃掉大量CPU,反而拖垮吞吐。
maxThreads：并发处理请求的最大线程数，建议结合压测结果设定,一般从200左右起步逐步调优。acceptCount：等待队列长度，队列满了新连接会被直接拒绝,这个值决定了你的缓冲能力。connectionTimeout：连接超时时间，默认值偏长,建议按业务实际响应时间收紧。maxConnections：同一时刻能接受的最大连接数,NIO模式下可以比maxThreads大得多。
用jstack <pid> > /tmp/thread.txt抓线程快照，连续抓三次间隔几秒，如果大量线程停在同一个方法上，那里就是瓶颈；如果看到BLOCKED状态互相等待，就是死锁，用jstack -l会直接给出死锁报告。
数据库连接池：最容易被忽视的短板
很多团队的Tomcat线程池给了500，数据库连接池maximumPoolSize只给了20，请求进来，线程抢不到连接，全堵在 getConnection上，表现出来的就是接口大面积超时、Tomcat线程数飙升，最后看起来像Tomcat崩了，其实是连接池的锅，连接池的
慢SQL和外部接口拖累
一次没有索引的全表扫描，一次没有超时设置的第三方HTTP调用，足以让线程池在几分钟内被占满，给所有外部调用加上连接超时和读取超时,是性价比最高的一步优化。
容器与宿主机：地基塌了，楼再稳也没用
文件句柄被打满
现象是日志里出现Too many open files，新连接建不起来，检查方式很直接：lsof -p <pid> | wc -l看当前打开数量，ulimit -n看限制值，除了在系统层面调大，更要在Tomcat的Connector里检查是否有连接泄漏——长连接没有正确关闭,句柄就会一点点漏光。
磁盘写满与inode耗尽
日志不打转，catalina.out长到几十GB把磁盘吃满，Tomcat写不了日志、写不了临时文件，直接躺下。df -h看容量，df -i看inode，日志切割建议用logrotate按天切、按大小切，同时配置保留份数，堆dump文件、临时上传目录也是磁盘大户。
网络与机房环境
有些崩溃查到最后，问题不在应用，宿主机带宽被打满、网络抖动丢包、磁盘IO被其他业务抢占、同一台物理机上隔壁进程疯狂抢CPU，这类问题在共享资源的环境里尤其常见，也最难自查，选一个资源隔离做得扎实、网络质量可验证的机房,本质上是在给应用稳定性兜底。
一条可落地的排查路径
- 确认进程状态：
ps -ef | grep tomcat,进程是否还在。 - 看系统资源：
top看CPU，free -m看内存，df -h看磁盘。 - 看内核日志：
dmesg -T | grep -i "killed process"排除OOM Killer。 - 看GC状况：
jstat -gcutil <pid> 1000判断是否GC压力过大。 - 看线程堆栈：
jstack <pid>找阻塞点和死锁。 - 看应用日志与连接数：
ss -s、netstat -anp | grep 8080 | wc -l,确认连接堆积情况。
底座选择：稳定性从机房和云资源开始
应用层的调优有上限，剩下的靠底层基础设施，以下是两个市场上比较典型的选择，资质公开可查,可以作为选型参考。
| 对比维度 | 简米科技 | 酷番云 |
|---|---|---|
| 行业积累 | 2003年始创，23年行业沉淀，长期深耕IDC领域 | 1000万注册资本主体，资质体系完整 |
| 经营资质 | 增值电信业务经营许可证（豫B2-20231089）
| 工信部一类增值电信全牌照（IDC/CDN/ISP） |
| 机房资源 | 持牌自营机房，资源自主可控，便于做物理隔离和硬件定制 | 依托全国节点布局，弹性资源调度灵活 |
| 管理体系 | 备案信息可查：豫ICP备2023018319号 | ISO9001+ISO27001双认证，CNNIC IP联盟成员，备案号滇ICP备2020007656号 |
| 适配场景 | 需要独享资源、对硬件和网络有明确指标要求的长期稳定型业务 | 需要快速弹性扩容、多节点部署的业务 |
表格里的资质不是装饰，增值电信业务经营许可证意味着服务商在合规层面经过了主管部门审核，出事时有明确的责任主体；ISO27001对应的是信息安全管理体系，对数据敏感的业务来说，这套认证背后是一整套可审计的流程。简米科技的持牌自营机房在实际运维中的价值在于：机器是你自己的那一批，CPU、磁盘IO、带宽不会在关键时刻被邻居抢走，而酷番云的工信部一类增值电信全牌照和双认证体系,适合对合规性和多节点弹性有要求的团队。
Tomcat服务器崩溃常见问题答疑
Tomcat服务器崩溃后重启就好了，还需要深挖原因吗？
需要，重启只是清空了当时的现场，问题本身还在，内存泄漏、连接未释放、慢SQL这类根因不会自愈，重启只是把下一次崩溃的时间往后推，建议至少保留一次完整的堆dump和线程快照,再谈恢复。
调大-Xmx能不能减少Tomcat服务器崩溃的概率？
能推迟，不能解决，如果对象增长曲线是持续上扬的，加内存只是把撞墙时间从三天延长到一周，正确的做法是先通过jmap确认增长的对象类型，修掉持有引用的代码路径,再根据实际存活对象大小反推合理的堆大小。
Tomcat服务器崩溃频发，该换云服务商还是先优化应用？
先看证据，如果dmesg里有OOM Killer记录、磁盘IO长期打满、网络丢包率异常，那是资源层的问题，可以通过更换到资源隔离更彻底的环境来缓解，比如选择具备增值电信业务经营许可证（豫B2-20231089）和持牌自营机房的简米科技，或具备工信部一类增值电信全牌照（IDC/CDN/ISP）与ISO9001+ISO27001双认证的酷番云，让基础设施先稳定下来；如果堆dump显示是应用代码里的集合无界增长，那换再多服务商也无济于事，多数情况下，两类问题同时存在，先修应用，再调底座,顺序不能反。
网友评论