1. 问题背景与现象分析最近在排查一个线上服务异常时遇到了一个典型的OOMOutOfMemoryError问题。这个案例非常有意思因为它不仅涉及到内存溢出本身还引发了Tomcat线程模型的异常表现最终导致服务不可用。让我们先还原一下问题现场。1.1 问题现象还原开发同学使用EasyExcel处理文件上传时没有做分页处理导致内存溢出。这在EasyExcel官方文档中也有明确警告大文件解析必须使用分页模式。内存溢出后JVM频繁触发Full GC但由于内存压力过大GC无法有效回收内存最终抛出Java heap space错误。重要提示生产环境使用EasyExcel等大数据量处理工具时必须实现分页读取机制这是避免OOM的基本要求。1.2 OOM类型深度解析在Java中OOM错误有多种类型每种都对应不同的场景Java heap space最常见的内存溢出通常是对象分配过多或单个对象过大导致。我们的案例就属于这种。GC Overhead limit exceeded当JVM花费98%以上的时间进行GC但只回收不到2%的内存时会抛出。这通常是内存泄漏的标志。Metaspace元数据区存放类信息溢出常见于动态生成大量类的场景。Direct buffer memory直接内存溢出常见于NIO的ByteBuffer使用不当。Unable to create new native thread线程创建过多通常与系统ulimit设置有关。Requested array size exceeds VM limit尝试创建过大的数组。CodeCacheJIT编译代码缓存区溢出。在我们的案例中需要特别注意内存溢出和内存泄漏的区别内存溢出内存不足但对象仍可回收如大文件解析时的临时内存占用内存泄漏对象无法回收内存被永久占用如静态集合持续增长2. 异常现象的矛盾点2.1 表面现象的矛盾当OOM发生后我们观察到几个看似矛盾的现象内存确实被回收了Full GC停止内存使用下降但HTTP请求仍然失败报connection reset by peer错误Tomcat线程看似正常处于WAITING状态连接数监控显示backlog队列已满101/1002.2 关键问题定位这引出了两个核心问题什么是connection reset by peer这是TCP层面的错误表示对端重置了连接在我们的场景中是因为Tomcat的accept队列已满Tomcat线程在做什么通过arthas的thread命令查看发现工作线程都在等待任务但Acceptor和Poller线程神秘消失了3. Tomcat线程模型深度解析3.1 Reactor模式基础要理解这个问题必须深入Tomcat的线程模型。Tomcat的NIO实现基于Reactor模式这是高性能网络编程的经典模式。Doug Lee在《Scalable IO in Java》中总结了三种Reactor模型单Reactor单线程Redis 6.0前采用简单但无法利用多核且容易阻塞单Reactor多线程IO操作单线程业务处理多线程避免了业务阻塞IO多Reactor多线程Main Reactor负责acceptSub Reactor负责IO业务线程池处理请求Netty采用这种模型3.2 Tomcat的NIO实现Tomcat的NIO实现可以看作是多Reactor多线程的变种包含三类线程Acceptor线程负责接受新连接默认只有1个线程Poller线程负责检测就绪的IO事件默认CPU核心数Worker线程处理HTTP请求数量由maxThreads控制关键源码路径启动入口org.apache.tomcat.util.net.NioEndpoint#startInternalAcceptor实现org.apache.tomcat.util.net.Acceptor#runPoller实现org.apache.tomcat.util.net.NioEndpoint.Poller#run3.3 Tomcat线程池特点Tomcat的线程池与JDK的ThreadPoolExecutor有所不同优先创建线程直到maxThreads只有达到maxThreads后才会排队队列使用TaskQueue继承LinkedBlockingQueue但重写了offer逻辑这种设计是为了快速响应突发流量但需要合理设置maxThreads避免资源耗尽。4. 问题根因分析4.1 线程消失之谜通过arthas的thread命令我们发现Acceptor和Poller线程不见了。查看源码发现// Acceptor.run()片段 try { while (running) { // 接受连接... } } catch (Throwable t) { // 对于OOM等Error会直接抛出导致线程终止 }关键点Acceptor捕获Throwable但对Error直接抛出OOM属于Error会导致线程终止日志打印在异常处理之后所以看不到错误日志4.2 现象解释现在可以解释所有现象了OOM导致Acceptor/Poller线程崩溃没有Acceptor新连接堆积在OS层面backlogbacklog满后新连接被拒绝connection resetWorker线程无事可做WAITING状态内存回收后线程不会自动恢复5. 解决方案与最佳实践5.1 立即解决方案修复内存问题实现EasyExcel的分页读取增加内存监控和报警增强OOM处理Thread.setDefaultUncaughtExceptionHandler((t, e) - { if (t.getName().contains(Acceptor)) { log.error(Tomcat acceptor thread died, e); // 可以考虑重启服务 } });JVM参数优化-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dumps -XX:OnOutOfMemoryErrorkill -9 %p # 强制重启5.2 长期预防措施文件处理规范所有文件处理必须实现分页/流式处理设置单个请求内存上限Tomcat优化# 适当增大acceptCount server.tomcat.accept-count200 # 监控关键线程 management.endpoint.health.probes.enabledtrue监控体系监控Tomcat关键线程状态实现OOM自动重启机制建立内存使用趋势监控6. 深度思考与经验总结6.1 为什么Tomcat不捕获Error这是一个设计权衡Error通常表示不可恢复状态继续运行可能导致更严重问题牺牲单个请求保全整个服务6.2 生产环境诊断技巧Arthas高级用法# 监控线程创建/销毁 thread -b # 统计线程状态 thread --state BLOCKEDOS层面检查# 查看连接队列 ss -ltnp | grep java # 监控backlog使用 netstat -s | grep overflowed日志增强// 在Spring Boot中增加Tomcat生命周期监听 Bean public TomcatConnectorCustomizer connectorCustomizer() { return connector - { connector.addLifecycleListener(event - { if (event.getType().equals(AFTER_START)) { log.info(Tomcat started with protocol: {}, connector.getProtocolHandler().getClass().getName()); } }); }; }6.3 性能优化黄金法则理解比配置更重要先理解原理再调整参数避免盲目复制优化配置监控驱动优化没有监控就不要谈优化建立完整的指标监控体系渐进式改进每次只改一个参数评估效果后再继续这个案例给我们的核心启示是内存问题不只是内存问题。在分布式系统中局部故障可能引发连锁反应。作为工程师我们需要深入理解底层原理建立全面的监控体系设计弹性的故障处理机制保持对异常的敏感度记住每一个异常现象背后都隐藏着一个等待被发现的设计缺陷或优化机会。
