Tomcat假死与OOM故障排查实战

1. 从内存溢出到Tomcat假死：一次完整的故障排查实录

最近在排查一个线上服务异常问题时，遇到了典型的OOM（OutOfMemoryError）引发的Tomcat假死现象。整个过程涉及到内存分析、线程状态检查、Tomcat底层原理等多个技术点，值得记录下来与大家分享。

1.1 问题现象与初步定位

我们的系统在使用easyexcel处理大文件上传时，出现了Java heap space的OOM错误。通过dump文件分析和日志追踪，很快定位到问题根源：开发同学在使用easyexcel解析文件时，没有进行分页处理，导致一次性加载了整个大文件到内存中。

重要提示：easyexcel官方文档明确建议对大文件进行分片读取，这正是为了避免此类内存问题。实际开发中，对于任何可能处理大文件的场景，都必须考虑内存使用情况。

OOM发生后，系统开始频繁进行Full GC，但由于内存压力过大，GC无法有效回收内存，最终抛出OutOfMemoryError。这里需要区分两个重要概念：

• 内存溢出（OOM）：应用需要的内存超过了JVM配置的最大堆大小。通常是分配了大对象或短时间内创建了大量对象，但内存最终是可以被回收的。
• 内存泄漏（Memory Leak）：对象已经不再使用，但由于错误的引用关系无法被GC回收。随着时间推移，可用内存会逐渐减少。

用生活化的比喻来说：内存溢出就像一个人胃口突然变大，吃光了冰箱里的食物（内存），但消化后（GC后）食物空间又回来了；内存泄漏则像是食物被吃掉后，包装袋却永远留在冰箱里占用空间。

1.2 意料之外的后续现象

在OOM发生后，我们观察到一个奇怪的现象：虽然文件解析完成后内存确实被回收了，Full GC也停止了，但应用的HTTP请求仍然持续报错，错误信息是"connection reset by peer"。

从监控数据看，Tomcat的请求线程数和连接数在崩溃前后没有明显波动。这引出了两个核心问题：

1. 什么是"connection reset by peer"错误？
2. OOM发生后，Tomcat线程到底处于什么状态？

2. 深入排查连接问题

2.1 连接队列分析

首先检查系统的连接状态。通过以下命令查看指定端口(8100)的连接情况：

bash复制netstat -tlnp | grep 8100
netstat -anp | grep 8100

输出中我们发现了一个关键参数：backlog值为101。backlog表示TCP连接等待队列的长度，对应Tomcat的acceptCount参数（默认100）。当并发连接数超过backlog+1时，新连接就会被操作系统拒绝，表现为"connection reset by peer"错误。

2.2 线程状态检查

接下来我们使用Arthas工具检查Tomcat线程状态：

bash复制thread -n 10    # 查看CPU占用最高的10个线程
thread 1        # 查看特定线程的堆栈
thread --all | grep http  # 筛选HTTP相关线程

结果显示Tomcat的工作线程都处于WAITING状态，阻塞在TaskQueue.take()方法上。这说明线程池的任务队列是空的，工作线程都在等待新任务。

这就形成了一个矛盾的现象：

• 连接队列已满（backlog=101），新连接被拒绝
• 但工作线程却闲置，没有任务可处理

3. Tomcat线程模型解析

要理解这个矛盾现象，必须深入Tomcat的线程模型。Tomcat支持多种I/O模型（BIO/NIO/AIO/APR），现代版本默认使用NIO（非阻塞I/O）。

3.1 Reactor模式实现

Tomcat的NIO实现基于Reactor模式，具体来说是多Reactor多线程模型：

1. Acceptor线程：负责接受新连接
2. Poller线程：负责监听已建立连接的I/O事件
3. 工作线程池：处理实际的业务请求

这种设计可以用少量线程处理大量连接，是高性能服务器的常见架构。

3.2 关键线程参数

在Spring Boot中，有两个重要的Tomcat线程参数：

properties复制server.tomcat.min-spare-threads=10  # 最小工作线程数
server.tomcat.max-threads=200       # 最大工作线程数

与JDK线程池不同，Tomcat的线程池会先创建min-spare-threads个核心线程，当任务数超过核心线程数时，会继续创建线程直到max-threads。只有超过max-threads后，任务才会进入队列等待。

4. 问题根源分析

通过arthas的线程检查，我们发现一个关键现象：正常情况下应该存在的Acceptor和Poller线程，在故障时消失了！这解释了为什么会出现连接队列满但工作线程闲置的矛盾现象。

4.1 Acceptor线程的异常处理

查看Tomcat源码（NioEndpoint类），Acceptor线程虽然捕获了异常，但对于OOM这样的Error，选择重新抛出，导致线程终止。这意味着：

1. OOM会导致Acceptor线程退出
2. 没有Acceptor线程，新连接无法被接受
3. 已有的连接会被Poller线程继续处理，直到全部完成
4. 最终所有线程都会进入闲置状态

4.2 无痕的崩溃

更棘手的是，Acceptor线程在抛出OOM前没有记录日志（最新Tomcat版本也是如此）。这使得问题排查更加困难。为了捕获这类异常，可以设置全局异常处理器：

java复制Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
    if (t.getName().equals("http-nio-8100-Acceptor")) {
        log.error("Tomcat Acceptor error", e);
    }
});

5. 解决方案与最佳实践

基于以上分析，我们采取以下措施解决问题并预防类似情况：

5.1 立即修复方案

1. 优化文件处理：对easyexcel使用分片读取模式，避免大文件一次性加载

   java复制// 正确的分片读取方式
   EasyExcel.read(file, new AnalysisEventListener() {
       // 每读取一定数量后处理
       @Override
       public void invoke(Object data, AnalysisContext context) {
           // 处理数据
           if (needClear()) {
               context.readSheetHolder().clear();
           }
       }
   }).sheet().doRead();
   

2. JVM参数调整：添加OOM时自动dump内存的配置

   bash复制-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump
   

5.2 长期预防措施

1. 代码审查重点：

   • 所有文件处理操作必须检查内存使用
   • 流式处理大数据集时禁止全量加载
   • 第三方库使用前阅读其内存管理文档

2. 监控增强：

   bash复制# 监控Tomcat关键线程
   watch -n 5 'ps -eLf | grep tomcat | grep -E "Acceptor|Poller" | wc -l'
   
   # 监控连接队列
   watch -n 5 'netstat -anp | grep 8100 | grep ESTABLISHED | wc -l'
   

3. 容量规划：

   • 根据业务特点合理设置Tomcat参数：

     properties复制server.tomcat.accept-count=500  # 适当增大等待队列
     server.tomcat.max-threads=500   # 根据CPU核心数调整
     

   • 对可能的大文件操作进行内存需求评估

6. 经验总结与思考

这次故障排查给我几个重要启示：

1. OOM的影响比想象中严重：不仅影响当前请求，可能导致整个容器不可用。对于关键业务系统，应该：

   • 配置-XX:+ExitOnOutOfMemoryError让容器直接退出，由监控系统重启
   • 或者使用-XX:+CrashOnOutOfMemoryError生成crash日志后退出

2. Tomcat的线程模型理解很重要：了解Acceptor/Poller/Worker的分工，才能快速定位类似"有连接但无处理"的问题

3. 防御性编程的必要性：

   • 对第三方库的使用要做最坏情况假设
   • 资源密集型操作必须设置安全边界
   • 重要的线程应该有自己的异常处理和恢复机制

4. 监控的全面性：除了常规的CPU、内存监控，还需要关注：

   • 关键线程存活状态
   • TCP连接队列深度
   • 线程池活跃度

在实际生产环境中，这类问题往往不是单一因素导致，而是多个小问题叠加的结果。这就要求我们：

• 在设计和编码阶段就考虑异常情况
• 建立完善的监控和告警体系
• 定期进行故障演练，验证系统的容错能力

最后分享一个实用技巧：对于Java应用，可以定期使用如下命令检查关键线程状态，形成健康检查习惯：

bash复制# 检查Tomcat线程
jstack <pid> | grep -A 10 'Acceptor|Poller'
# 检查连接状态
ss -antp | grep <port>