1. 从一次线上告警说起Tomcat假死服务“静默”的危机那天下午监控大屏上一个服务接口的响应时间曲线突然拉成了一条直线紧接着错误告警的短信和钉钉消息开始刷屏。登录服务器一看Tomcat进程还在ps命令显示它“活”得好好的CPU和内存占用也不算离谱但就是所有HTTP请求都石沉大海返回504超时。这就是典型的Tomcat“假死”——它没有崩溃Crash也没有退出而是进入了某种“植物人”状态对外部请求失去响应。对于任何线上系统来说这比直接宕机更棘手因为它具有欺骗性常规的健康检查可能无法及时发现。今天我就结合多年踩坑经验系统性地梳理一下当你的Tomcat服务“静默”时应该如何像老中医一样“望闻问切”一步步定位到病灶根因。假死问题之所以复杂是因为它往往是系统深层矛盾积累到一定程度后的集中爆发表象单一无响应但诱因却可能遍布应用代码、中间件配置、操作系统资源乃至网络环境。排查的核心思路是从外到内从表象到本质层层递进。我们将遵循“先整体后局部先资源后逻辑”的原则构建一套可复用的排查框架。2. 第一现场快速诊断与信息收集当告警响起时间就是金钱。盲目重启虽然能暂时恢复服务但会丢失宝贵的现场信息让问题根因石沉大海。正确的做法是在决定重启前尽可能完成一轮快速诊断和信息收集。2.1 基础状态检查确认“假死”而非“真死”首先我们需要确认Tomcat进程确实存在且未被操作系统挂起。# 查看Tomcat进程状态 ps -ef | grep tomcat # 或使用jps查看Java进程 jps -l如果进程存在接着检查其资源占用情况这能快速排除一些明显的资源瓶颈。# 查看进程的CPU和内存概况 top -p tomcat_pid # 更详细的内存分析 cat /proc/tomcat_pid/status | grep -E ‘VmPeak|VmSize|VmRSS|Threads’关键指标解读CPU如果CPU占用率持续100%或接近100%且主要是用户态us占用很可能是某个或某几个线程陷入了死循环或密集型计算。如果是系统态sy占用高则可能与频繁的IO等待、线程上下文切换或系统调用有关。内存关注VmRSS常驻物理内存。如果它持续增长且接近系统可用内存上限或VmPeak峰值虚拟内存异常高强烈怀疑内存泄漏。但注意Java应用更应关注堆内存这需要后续用jstat工具。线程数Threads字段显示进程内的线程总数。如果线程数异常增多例如达到几千甚至上万远超应用配置可能是线程池配置不当或任务处理过慢导致线程堆积。2.2 网络连接分析揪出“CLOSE_WAIT”幽灵网络连接状态是排查假死问题的金矿。大量的CLOSE_WAIT状态连接是导致Tomcat线程池耗尽的经典元凶。# 统计Tomcat进程的各种网络连接状态数量 netstat -antp | grep tomcat_pid | awk ‘{print $6}’ | sort | uniq -c | sort -rn # 或者使用更现代的ss命令 ss -antp | grep tomcat_pid重点关注CLOSE_WAITTCP连接关闭是四次挥手的过程。当服务端收到客户端的FIN包并回复ACK后连接进入CLOSE_WAIT状态等待服务端应用程序主动调用close()来发送最终的FIN包。如果应用程序例如你的代码中使用了HTTP客户端而未正确关闭连接没有调用close这个连接就会一直停留在CLOSE_WAIT状态占用一个文件描述符和可能的线程资源。当这种连接成千上万时就会耗尽资源导致假死。注意TIME_WAIT是主动关闭连接的一方通常是你的Tomcat作为客户端调用外部服务时会出现的状态数量过多也会占用资源但其有2MSL的生存周期一般不是假死的直接原因更多是性能瓶颈的指示。2.3 服务端口探活验证应用层无响应进程在、资源看似正常那应用本身呢使用curl或telnet进行简单探活。# 测试Tomcat默认的HTTP端口是否可连接 telnet localhost 8080 # 连接成功后尝试发送一个最简单的HTTP请求头 GET / HTTP/1.1 Host: localhost # 使用curl带超时设置模拟客户端请求 curl -v -m 5 http://localhost:8080/your-app/health如果telnet连接成功但输入HTTP请求后无任何回应或者curl命令超时这基本坐实了应用层面的“假死”——TCP连接能建立但应用线程无法处理请求。完成以上三步我们已经可以确认问题现象并有了初步的方向如资源耗尽、连接堆积。接下来我们需要深入JVM和应用程序内部。3. 深入JVM腹地线程、堆栈与堆内存分析Java应用的假死十有八九能在JVM层面找到线索。我们需要获取Tomcat进程的线程转储Thread Dump和堆内存转储Heap Dump进行分析。3.1 获取并分析线程转储Thread Dump线程转储记录了JVM中所有线程在某一时刻的执行状态即调用栈这是分析死锁、死循环、线程阻塞的利器。获取方式# 最常用的jstack命令 jstack -l tomcat_pid thread_dump_$(date %Y%m%d%H%M%S).txt # 如果jstack无响应假死严重时可能发生可以使用kill信号 kill -3 tomcat_pid # 输出会打印到Tomcat的catalina.out或标准输出分析线程转储打开生成的txt文件我们需要关注以下几点线程状态重点关注BLOCKED阻塞、WAITING等待、TIMED_WAITING超时等待的线程。特别是大量线程停留在同一个锁或同一个条件上。死锁检测jstack输出末尾通常会有一个“Found one Java-level deadlock:”部分这里会清晰指出发生死锁的线程和它们互相持有的锁。这与热词中的“HashMap死锁”有关在Java 7及之前版本的HashMap注意不是Hashtable或ConcurrentHashMap在并发扩容时确实可能因环形链表导致CPU 100%的问题严格说不是死锁是死循环但在Java 8中已通过算法改进大幅缓解。更常见的死锁发生在业务代码的synchronized块或ReentrantLock使用不当时。线程池状态查找名为“http-nio-8080-exec-XXX”或“tp-XXX”取决于你使用的连接器线程池名称的线程。如果大量这样的线程都处于WAITING状态可能意味着没有任务但如果它们都卡在某个特定的业务方法调用栈上比如都在等待数据库连接那瓶颈就很明确了。I/O等待线程状态为RUNNABLE但调用栈显示在SocketInputStream.socketRead0等Native方法处这表示线程在等待网络IO需要结合网络连接状态分析。一个典型的死锁栈示例“Thread-1” #12 prio5 os_prio0 tid0x00007f48740f4800 nid0x4a3d waiting for monitor entry [0x00007f483b7f6000] java.lang.Thread.State: BLOCKED (on object monitor at 0x00000000f5d8d5d8) at com.example.DeadLockClass.methodA(DeadLockClass.java:20) - waiting to lock 0x00000000f5d8d5e0 (a java.lang.Object) - locked 0x00000000f5d8d5d8 (a java.lang.Object) “Thread-2” #13 prio5 os_prio0 tid0x00007f48740f6000 nid0x4a3e waiting for monitor entry [0x00007f483b6f5000] java.lang.Thread.State: BLOCKED (on object monitor at 0x00000000f5d8d5e0) at com.example.DeadLockClass.methodB(DeadLockClass.java:30) - waiting to lock 0x00000000f5d8d5d8 (a java.lang.Object) - locked 0x00000000f5d8d5e0 (a java.lang.Object)这里清晰地显示Thread-1锁住了对象0xf5d8d5d8试图获取0xf5d8d5e0而Thread-2锁住了0xf5d8d5e0试图获取0xf5d8d5d8形成了经典的交叉死锁。3.2 监控堆内存与GC情况内存泄漏导致的频繁Full GC甚至GC线程本身出现问题也会引发应用长时间停顿表现为假死。使用jstat工具监控GC# 每2秒采样一次共采样10次观察GC情况 jstat -gcutil tomcat_pid 2000 10关键列EEden区使用率、O老年代使用率、M元空间使用率如果老年代使用率O持续增长甚至在每次Full GC后也只升不降是内存泄漏的强信号。FGCFull GC次数、FGCTFull GC总时间如果FGC在短时间内急剧增加且FGCT很长说明系统正在经历“GC风暴”应用线程会因Stop-The-World而长时间无法响应。如果怀疑内存泄漏需要获取堆内存转储进行深度分析# 使用jmap生成堆转储文件生产环境慎用文件较大可能引起停顿 jmap -dump:live,formatb,fileheap_dump.hprof tomcat_pid可以使用Eclipse MAT或JProfiler等工具分析hprof文件查看占用内存最大的对象是哪些以及它们的引用链从而定位泄漏点。常见的泄漏源包括未关闭的数据库连接池、静态集合类不当缓存、监听器未注销、线程局部变量ThreadLocal未清理等。3.3 检查JVM自身与Native代码极少数情况下问题可能出在JVM内部或Native代码如通过JNI调用的库。可以查看GC日志如果开启是否有异常或者使用straceLinux跟踪系统调用strace -f -p tomcat_pid -o strace.out分析strace.out看进程是否卡在某个特定的系统调用上如futex等待、epoll_wait或某个文件/网络IO操作。4. 应用层与中间件专项排查当JVM层面没有发现明显异常如无死锁、GC正常我们就需要将目光投向应用代码和Tomcat自身的配置。4.1 数据库连接池隐藏的资源黑洞这是导致假死的超级高频原因。配置不当或连接泄漏的连接池会迅速耗光资源。检查配置查看application.properties或datasource配置关注maximumPoolSize、connectionTimeout、idleTimeout等参数。连接池最大尺寸是否过小获取连接的超时时间是否合理检查泄漏大多数连接池如HikariCP、Druid都提供监控端点或JMX MBean。查看活跃连接数是否持续等于最大连接数且长时间不释放是否存在未关闭的Connection、Statement或ResultSetDruid内置了泄漏检测功能可以开启。数据库侧状态在数据库服务器上查询来自问题应用服务器的连接状态。是否存在大量Sleep状态的连接这可能是应用端连接池未正确关闭连接。4.2 Tomcat连接器与线程池配置Tomcat处理请求的引擎是连接器Connector其配置直接影响并发处理能力。 检查server.xml中Connector的配置Connector port“8080” protocol“HTTP/1.1” connectionTimeout“20000” maxThreads“200” !-- 最大工作线程数 -- minSpareThreads“10” !-- 最小空闲线程 -- acceptCount“100” !-- 等待队列长度 -- maxConnections“10000” !-- 最大连接数 -- ... /maxThreads设置过小当并发请求数超过此值时新请求将排队等待。如果业务处理慢队列会快速积压最终导致新请求超时。acceptCount设置过大等待队列太长虽然不会立即拒绝连接但请求在队列中的等待时间会被计入响应时间用户体验极差且掩盖了真正的性能瓶颈。connectionTimeout这个超时是针对从读取请求到响应完成的整个过程的。如果业务处理时间超过此值连接会被Tomcat主动关闭可能导致客户端收到不完整的响应。一个常见的误区是盲目调大maxThreads。线程数增加会带来更多的内存开销每个线程有独立的栈和CPU上下文切换成本。最佳实践是通过压测找到应用的瓶颈通常是CPU或数据库然后设置一个略高于瓶颈饱和点的线程数。4.3 同步与锁竞争即使没有死锁激烈的锁竞争也会导致大量线程阻塞大幅降低吞吐量在压力下表现为服务停滞。检查代码中的同步块是否在大的方法上粗粒度地使用了synchronized是否在高并发场景下使用了HashMap而非ConcurrentHashMap使用jstack分析锁竞争如果大量线程都处于BLOCKED状态且等待的是同一个锁对象地址说明该锁是热点竞争资源。需要考虑减小锁粒度、使用读写锁ReentrantReadWriteLock或改用无锁数据结构。第三方库/框架的锁某些框架或工具库内部也可能存在同步问题。升级版本或寻找替代库可能是解决方案。4.4 外部依赖与慢调用现代应用是分布式系统Tomcat假死可能是被下游依赖服务“拖死”的。HTTP客户端调用检查应用中所有对外HTTP调用如使用RestTemplate、Feign、OkHttp等。是否设置了连接超时connectTimeout和读取超时readTimeout如果没有设置或设置过长当下游服务响应慢或宕机时调用线程会被无限期挂起。数据库慢查询一个没有索引的全表扫描大查询不仅自己慢还可能锁表阻塞其他所有数据库操作。远程过程调用RPC如Dubbo、gRPC调用同样需要检查超时设置和熔断降级机制是否开启。排查工具可以使用Arthas的trace命令跟踪某个请求的完整调用链精确找出耗时最长的环节。5. 系统与环境层被忽略的底层因素如果应用和JVM层都找不到问题那可能需要将视线下移到操作系统和运行环境。5.1 文件描述符耗尽Linux系统中每个进程能打开的文件数量是有限制的包括socket连接它也是文件描述符。当Tomcat建立的连接数包括数据库连接、Redis连接、对外HTTP连接等超过这个限制时新的连接将无法建立。# 查看Tomcat进程当前使用的文件描述符数量 ls -l /proc/tomcat_pid/fd | wc -l # 查看系统全局和用户级的文件描述符限制 ulimit -n cat /proc/sys/fs/file-max如果ls命令的结果接近ulimit -n显示的限制就需要调大限制或在应用层面解决连接泄漏问题。5.2 网络参数配置系统的网络参数也可能成为瓶颈。例如net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle后者在较新内核中已废弃会影响TIME_WAIT连接的复用net.core.somaxconn定义了Socket监听队列的最大长度如果Tomcat的acceptCount设置大于此值实际队列长度以此系统参数为准。5.3 容器化环境特有问题如果你的Tomcat运行在Docker或Kubernetes中如热词提到的podman ps、kubernetes通用故障排查思路还需要考虑资源限制容器是否设置了合理的CPU和内存限制limits当应用试图分配超过limit的内存时可能会被OOM Killer直接终止。CPU限制可能导致进程调度缓慢。存储卷挂载如果日志或临时文件写入挂载的卷而该卷的存储后端出现故障或延迟可能导致IO阻塞。Sidecar与服务网格如果使用了Istio等Service Mesh网络流量会被Sidecar代理拦截。需要检查Sidecar容器的状态和资源占用。5.4 硬件与虚拟化层在极端情况下问题可能源于底层硬件或虚拟化平台。例如宿主机CPU调度异常、网络虚拟化故障、共享存储性能骤降等。这需要系统管理员配合查看宿主机监控、Hypervisor日志等。6. 构建防御体系从被动排查到主动预防排查假死问题固然重要但更好的策略是防患于未然。建立一套完善的监控和防御体系能让问题在萌芽阶段就被发现。完善监控指标除了基础的CPU、内存、磁盘、网络必须监控JVM堆内存各分区使用率、GC频率与耗时、线程池活跃线程数/队列大小。Tomcat当前连接数、繁忙线程数、请求处理时间、错误计数。应用业务关键接口的TPS、响应时间P50, P95, P99、错误率。外部依赖数据库连接池使用率、Redis缓存命中率、下游服务调用耗时与成功率。设置智能告警不要只对“服务宕机”告警。应对以下情况设置预警线程池使用率持续高于80%。Full GC频率在10分钟内超过3次。CLOSE_WAIT连接数超过阈值如100个。关键接口P99响应时间连续上涨。定期进行健康检查与压测通过定期的全链路压测摸清系统的容量边界提前发现性能瓶颈和资源泄漏点。使用Chaos Engineering工具模拟依赖服务延迟、故障检验系统的韧性。代码与配置规范强制要求所有HTTP客户端、数据库连接池必须设置合理的超时时间。使用连接池时务必在finally块中或使用try-with-resources语句确保连接归还。避免在静态集合或缓存中无限制地存放对象需有明确的过期或淘汰策略。对Tomcat、JVM参数进行调优并记录基准值任何变更都应有回滚方案。假死问题的排查是一场从现象到本质的侦探游戏。它没有一成不变的答案但有一套可循的方法论。从最外层的系统状态和网络连接入手逐步深入到JVM线程、内存再到应用代码和配置最后审视运行环境。每一次成功的排查不仅解决了一次故障更是对系统认知的一次深化。记住最重要的不是记住所有命令而是理解每个检查步骤背后的原理和它所要揭示的问题。这样当下一次告警响起时你就能成竹在胸快速定位到那个让Tomcat“静默”的真凶。
1. 从一次线上告警说起Tomcat假死服务“静默”的危机那天下午监控大屏上一个服务接口的响应时间曲线突然拉成了一条直线紧接着错误告警的短信和钉钉消息开始刷屏。登录服务器一看Tomcat进程还在ps命令显示它“活”得好好的CPU和内存占用也不算离谱但就是所有HTTP请求都石沉大海返回504超时。这就是典型的Tomcat“假死”——它没有崩溃Crash也没有退出而是进入了某种“植物人”状态对外部请求失去响应。对于任何线上系统来说这比直接宕机更棘手因为它具有欺骗性常规的健康检查可能无法及时发现。今天我就结合多年踩坑经验系统性地梳理一下当你的Tomcat服务“静默”时应该如何像老中医一样“望闻问切”一步步定位到病灶根因。假死问题之所以复杂是因为它往往是系统深层矛盾积累到一定程度后的集中爆发表象单一无响应但诱因却可能遍布应用代码、中间件配置、操作系统资源乃至网络环境。排查的核心思路是从外到内从表象到本质层层递进。我们将遵循“先整体后局部先资源后逻辑”的原则构建一套可复用的排查框架。2. 第一现场快速诊断与信息收集当告警响起时间就是金钱。盲目重启虽然能暂时恢复服务但会丢失宝贵的现场信息让问题根因石沉大海。正确的做法是在决定重启前尽可能完成一轮快速诊断和信息收集。2.1 基础状态检查确认“假死”而非“真死”首先我们需要确认Tomcat进程确实存在且未被操作系统挂起。# 查看Tomcat进程状态 ps -ef | grep tomcat # 或使用jps查看Java进程 jps -l如果进程存在接着检查其资源占用情况这能快速排除一些明显的资源瓶颈。# 查看进程的CPU和内存概况 top -p tomcat_pid # 更详细的内存分析 cat /proc/tomcat_pid/status | grep -E ‘VmPeak|VmSize|VmRSS|Threads’关键指标解读CPU如果CPU占用率持续100%或接近100%且主要是用户态us占用很可能是某个或某几个线程陷入了死循环或密集型计算。如果是系统态sy占用高则可能与频繁的IO等待、线程上下文切换或系统调用有关。内存关注VmRSS常驻物理内存。如果它持续增长且接近系统可用内存上限或VmPeak峰值虚拟内存异常高强烈怀疑内存泄漏。但注意Java应用更应关注堆内存这需要后续用jstat工具。线程数Threads字段显示进程内的线程总数。如果线程数异常增多例如达到几千甚至上万远超应用配置可能是线程池配置不当或任务处理过慢导致线程堆积。2.2 网络连接分析揪出“CLOSE_WAIT”幽灵网络连接状态是排查假死问题的金矿。大量的CLOSE_WAIT状态连接是导致Tomcat线程池耗尽的经典元凶。# 统计Tomcat进程的各种网络连接状态数量 netstat -antp | grep tomcat_pid | awk ‘{print $6}’ | sort | uniq -c | sort -rn # 或者使用更现代的ss命令 ss -antp | grep tomcat_pid重点关注CLOSE_WAITTCP连接关闭是四次挥手的过程。当服务端收到客户端的FIN包并回复ACK后连接进入CLOSE_WAIT状态等待服务端应用程序主动调用close()来发送最终的FIN包。如果应用程序例如你的代码中使用了HTTP客户端而未正确关闭连接没有调用close这个连接就会一直停留在CLOSE_WAIT状态占用一个文件描述符和可能的线程资源。当这种连接成千上万时就会耗尽资源导致假死。注意TIME_WAIT是主动关闭连接的一方通常是你的Tomcat作为客户端调用外部服务时会出现的状态数量过多也会占用资源但其有2MSL的生存周期一般不是假死的直接原因更多是性能瓶颈的指示。2.3 服务端口探活验证应用层无响应进程在、资源看似正常那应用本身呢使用curl或telnet进行简单探活。# 测试Tomcat默认的HTTP端口是否可连接 telnet localhost 8080 # 连接成功后尝试发送一个最简单的HTTP请求头 GET / HTTP/1.1 Host: localhost # 使用curl带超时设置模拟客户端请求 curl -v -m 5 http://localhost:8080/your-app/health如果telnet连接成功但输入HTTP请求后无任何回应或者curl命令超时这基本坐实了应用层面的“假死”——TCP连接能建立但应用线程无法处理请求。完成以上三步我们已经可以确认问题现象并有了初步的方向如资源耗尽、连接堆积。接下来我们需要深入JVM和应用程序内部。3. 深入JVM腹地线程、堆栈与堆内存分析Java应用的假死十有八九能在JVM层面找到线索。我们需要获取Tomcat进程的线程转储Thread Dump和堆内存转储Heap Dump进行分析。3.1 获取并分析线程转储Thread Dump线程转储记录了JVM中所有线程在某一时刻的执行状态即调用栈这是分析死锁、死循环、线程阻塞的利器。获取方式# 最常用的jstack命令 jstack -l tomcat_pid thread_dump_$(date %Y%m%d%H%M%S).txt # 如果jstack无响应假死严重时可能发生可以使用kill信号 kill -3 tomcat_pid # 输出会打印到Tomcat的catalina.out或标准输出分析线程转储打开生成的txt文件我们需要关注以下几点线程状态重点关注BLOCKED阻塞、WAITING等待、TIMED_WAITING超时等待的线程。特别是大量线程停留在同一个锁或同一个条件上。死锁检测jstack输出末尾通常会有一个“Found one Java-level deadlock:”部分这里会清晰指出发生死锁的线程和它们互相持有的锁。这与热词中的“HashMap死锁”有关在Java 7及之前版本的HashMap注意不是Hashtable或ConcurrentHashMap在并发扩容时确实可能因环形链表导致CPU 100%的问题严格说不是死锁是死循环但在Java 8中已通过算法改进大幅缓解。更常见的死锁发生在业务代码的synchronized块或ReentrantLock使用不当时。线程池状态查找名为“http-nio-8080-exec-XXX”或“tp-XXX”取决于你使用的连接器线程池名称的线程。如果大量这样的线程都处于WAITING状态可能意味着没有任务但如果它们都卡在某个特定的业务方法调用栈上比如都在等待数据库连接那瓶颈就很明确了。I/O等待线程状态为RUNNABLE但调用栈显示在SocketInputStream.socketRead0等Native方法处这表示线程在等待网络IO需要结合网络连接状态分析。一个典型的死锁栈示例“Thread-1” #12 prio5 os_prio0 tid0x00007f48740f4800 nid0x4a3d waiting for monitor entry [0x00007f483b7f6000] java.lang.Thread.State: BLOCKED (on object monitor at 0x00000000f5d8d5d8) at com.example.DeadLockClass.methodA(DeadLockClass.java:20) - waiting to lock 0x00000000f5d8d5e0 (a java.lang.Object) - locked 0x00000000f5d8d5d8 (a java.lang.Object) “Thread-2” #13 prio5 os_prio0 tid0x00007f48740f6000 nid0x4a3e waiting for monitor entry [0x00007f483b6f5000] java.lang.Thread.State: BLOCKED (on object monitor at 0x00000000f5d8d5e0) at com.example.DeadLockClass.methodB(DeadLockClass.java:30) - waiting to lock 0x00000000f5d8d5d8 (a java.lang.Object) - locked 0x00000000f5d8d5e0 (a java.lang.Object)这里清晰地显示Thread-1锁住了对象0xf5d8d5d8试图获取0xf5d8d5e0而Thread-2锁住了0xf5d8d5e0试图获取0xf5d8d5d8形成了经典的交叉死锁。3.2 监控堆内存与GC情况内存泄漏导致的频繁Full GC甚至GC线程本身出现问题也会引发应用长时间停顿表现为假死。使用jstat工具监控GC# 每2秒采样一次共采样10次观察GC情况 jstat -gcutil tomcat_pid 2000 10关键列EEden区使用率、O老年代使用率、M元空间使用率如果老年代使用率O持续增长甚至在每次Full GC后也只升不降是内存泄漏的强信号。FGCFull GC次数、FGCTFull GC总时间如果FGC在短时间内急剧增加且FGCT很长说明系统正在经历“GC风暴”应用线程会因Stop-The-World而长时间无法响应。如果怀疑内存泄漏需要获取堆内存转储进行深度分析# 使用jmap生成堆转储文件生产环境慎用文件较大可能引起停顿 jmap -dump:live,formatb,fileheap_dump.hprof tomcat_pid可以使用Eclipse MAT或JProfiler等工具分析hprof文件查看占用内存最大的对象是哪些以及它们的引用链从而定位泄漏点。常见的泄漏源包括未关闭的数据库连接池、静态集合类不当缓存、监听器未注销、线程局部变量ThreadLocal未清理等。3.3 检查JVM自身与Native代码极少数情况下问题可能出在JVM内部或Native代码如通过JNI调用的库。可以查看GC日志如果开启是否有异常或者使用straceLinux跟踪系统调用strace -f -p tomcat_pid -o strace.out分析strace.out看进程是否卡在某个特定的系统调用上如futex等待、epoll_wait或某个文件/网络IO操作。4. 应用层与中间件专项排查当JVM层面没有发现明显异常如无死锁、GC正常我们就需要将目光投向应用代码和Tomcat自身的配置。4.1 数据库连接池隐藏的资源黑洞这是导致假死的超级高频原因。配置不当或连接泄漏的连接池会迅速耗光资源。检查配置查看application.properties或datasource配置关注maximumPoolSize、connectionTimeout、idleTimeout等参数。连接池最大尺寸是否过小获取连接的超时时间是否合理检查泄漏大多数连接池如HikariCP、Druid都提供监控端点或JMX MBean。查看活跃连接数是否持续等于最大连接数且长时间不释放是否存在未关闭的Connection、Statement或ResultSetDruid内置了泄漏检测功能可以开启。数据库侧状态在数据库服务器上查询来自问题应用服务器的连接状态。是否存在大量Sleep状态的连接这可能是应用端连接池未正确关闭连接。4.2 Tomcat连接器与线程池配置Tomcat处理请求的引擎是连接器Connector其配置直接影响并发处理能力。 检查server.xml中Connector的配置Connector port“8080” protocol“HTTP/1.1” connectionTimeout“20000” maxThreads“200” !-- 最大工作线程数 -- minSpareThreads“10” !-- 最小空闲线程 -- acceptCount“100” !-- 等待队列长度 -- maxConnections“10000” !-- 最大连接数 -- ... /maxThreads设置过小当并发请求数超过此值时新请求将排队等待。如果业务处理慢队列会快速积压最终导致新请求超时。acceptCount设置过大等待队列太长虽然不会立即拒绝连接但请求在队列中的等待时间会被计入响应时间用户体验极差且掩盖了真正的性能瓶颈。connectionTimeout这个超时是针对从读取请求到响应完成的整个过程的。如果业务处理时间超过此值连接会被Tomcat主动关闭可能导致客户端收到不完整的响应。一个常见的误区是盲目调大maxThreads。线程数增加会带来更多的内存开销每个线程有独立的栈和CPU上下文切换成本。最佳实践是通过压测找到应用的瓶颈通常是CPU或数据库然后设置一个略高于瓶颈饱和点的线程数。4.3 同步与锁竞争即使没有死锁激烈的锁竞争也会导致大量线程阻塞大幅降低吞吐量在压力下表现为服务停滞。检查代码中的同步块是否在大的方法上粗粒度地使用了synchronized是否在高并发场景下使用了HashMap而非ConcurrentHashMap使用jstack分析锁竞争如果大量线程都处于BLOCKED状态且等待的是同一个锁对象地址说明该锁是热点竞争资源。需要考虑减小锁粒度、使用读写锁ReentrantReadWriteLock或改用无锁数据结构。第三方库/框架的锁某些框架或工具库内部也可能存在同步问题。升级版本或寻找替代库可能是解决方案。4.4 外部依赖与慢调用现代应用是分布式系统Tomcat假死可能是被下游依赖服务“拖死”的。HTTP客户端调用检查应用中所有对外HTTP调用如使用RestTemplate、Feign、OkHttp等。是否设置了连接超时connectTimeout和读取超时readTimeout如果没有设置或设置过长当下游服务响应慢或宕机时调用线程会被无限期挂起。数据库慢查询一个没有索引的全表扫描大查询不仅自己慢还可能锁表阻塞其他所有数据库操作。远程过程调用RPC如Dubbo、gRPC调用同样需要检查超时设置和熔断降级机制是否开启。排查工具可以使用Arthas的trace命令跟踪某个请求的完整调用链精确找出耗时最长的环节。5. 系统与环境层被忽略的底层因素如果应用和JVM层都找不到问题那可能需要将视线下移到操作系统和运行环境。5.1 文件描述符耗尽Linux系统中每个进程能打开的文件数量是有限制的包括socket连接它也是文件描述符。当Tomcat建立的连接数包括数据库连接、Redis连接、对外HTTP连接等超过这个限制时新的连接将无法建立。# 查看Tomcat进程当前使用的文件描述符数量 ls -l /proc/tomcat_pid/fd | wc -l # 查看系统全局和用户级的文件描述符限制 ulimit -n cat /proc/sys/fs/file-max如果ls命令的结果接近ulimit -n显示的限制就需要调大限制或在应用层面解决连接泄漏问题。5.2 网络参数配置系统的网络参数也可能成为瓶颈。例如net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle后者在较新内核中已废弃会影响TIME_WAIT连接的复用net.core.somaxconn定义了Socket监听队列的最大长度如果Tomcat的acceptCount设置大于此值实际队列长度以此系统参数为准。5.3 容器化环境特有问题如果你的Tomcat运行在Docker或Kubernetes中如热词提到的podman ps、kubernetes通用故障排查思路还需要考虑资源限制容器是否设置了合理的CPU和内存限制limits当应用试图分配超过limit的内存时可能会被OOM Killer直接终止。CPU限制可能导致进程调度缓慢。存储卷挂载如果日志或临时文件写入挂载的卷而该卷的存储后端出现故障或延迟可能导致IO阻塞。Sidecar与服务网格如果使用了Istio等Service Mesh网络流量会被Sidecar代理拦截。需要检查Sidecar容器的状态和资源占用。5.4 硬件与虚拟化层在极端情况下问题可能源于底层硬件或虚拟化平台。例如宿主机CPU调度异常、网络虚拟化故障、共享存储性能骤降等。这需要系统管理员配合查看宿主机监控、Hypervisor日志等。6. 构建防御体系从被动排查到主动预防排查假死问题固然重要但更好的策略是防患于未然。建立一套完善的监控和防御体系能让问题在萌芽阶段就被发现。完善监控指标除了基础的CPU、内存、磁盘、网络必须监控JVM堆内存各分区使用率、GC频率与耗时、线程池活跃线程数/队列大小。Tomcat当前连接数、繁忙线程数、请求处理时间、错误计数。应用业务关键接口的TPS、响应时间P50, P95, P99、错误率。外部依赖数据库连接池使用率、Redis缓存命中率、下游服务调用耗时与成功率。设置智能告警不要只对“服务宕机”告警。应对以下情况设置预警线程池使用率持续高于80%。Full GC频率在10分钟内超过3次。CLOSE_WAIT连接数超过阈值如100个。关键接口P99响应时间连续上涨。定期进行健康检查与压测通过定期的全链路压测摸清系统的容量边界提前发现性能瓶颈和资源泄漏点。使用Chaos Engineering工具模拟依赖服务延迟、故障检验系统的韧性。代码与配置规范强制要求所有HTTP客户端、数据库连接池必须设置合理的超时时间。使用连接池时务必在finally块中或使用try-with-resources语句确保连接归还。避免在静态集合或缓存中无限制地存放对象需有明确的过期或淘汰策略。对Tomcat、JVM参数进行调优并记录基准值任何变更都应有回滚方案。假死问题的排查是一场从现象到本质的侦探游戏。它没有一成不变的答案但有一套可循的方法论。从最外层的系统状态和网络连接入手逐步深入到JVM线程、内存再到应用代码和配置最后审视运行环境。每一次成功的排查不仅解决了一次故障更是对系统认知的一次深化。记住最重要的不是记住所有命令而是理解每个检查步骤背后的原理和它所要揭示的问题。这样当下一次告警响起时你就能成竹在胸快速定位到那个让Tomcat“静默”的真凶。
)
