我们生产最近有个服务偶尔会挂掉接口报错connection reset by peer上服务器curl也是同样报错意思连接被server拒绝了。通过dump以及日志分析我们已经知道了问题代码所在就是使用easyexcel上传、解析文件开发同学没有做分页导致内存溢出。这点在easyexcel文档也有提到参见。内存溢出后触发频繁的full gc由于gc很难有效回收内存所以程序抛出了OutOfMemoryError原因是Java heap space。关于OOM的异常原因我们也需要知道有如下几种Java heap space内存无法分配新的对象。典型的场景是内存不足内存泄漏分配的对象过大。GC Overhead limit exceededgc回收异常多次发生了98%的时间用于gc但只回收2%的内存。典型的场景是内存不足内存泄漏。Metaspace元空间不足。典型的场景是元空间设置太小程序异常创建过多的Class。Direct buffer memory直接内存不足。典型的场景是直接内存设置太小直接内存泄漏。Unable to create new native thread无法创建新的线程。典型的场景是系统ulimit -u设置太小。Requested array size exceeds VM limi数组大小太大。典型的场景是new ClassA[Long.MAX_VALUE]CodeCachejit编译缓存溢出。典型的场景是jit缓存设置过小。注意我们上面提到问题的是内存溢出而不是内存泄漏两者有本质的区别。内存溢出通常是分配大对象应用内存不足通常分配多点空间就可以解决问题而且所占的内存用完还是可以被回收的。内存泄漏则是程序有问题内存是无法被回收的分配再多的空间也都会被慢慢消耗完。打个比方内存溢出只是人长得不好看不是坏人内存泄漏则长得不好看也是坏人。当然两者我们都需要对其进行优化。通过我们的观察也发现确实如此经过一段时间后文件解析数据处理完内存就被回收了也没有full gc了。但问题来了此时应用http请求还是继续报错的依然是connection reset by peer。这点就不好理解了应用恢复了为什么tomcat没有恢复tomcat线程此时在做什么从日志也看不到tomcat相关错误tomcat假死了。从监控上看挂掉之前tomcat的请求线程数和连接数没有什么波动。我们的两个核心问题是什么是connection reset by peertomcat线程此时处于什么状态连接报错我们搜索源码并没有抛出connection reset by peer的代码也就是可能是jvm层面的抛出或者系统层面的抛出。既然是跟connection相关那我们就用netstat命令看下当前进程的连接情况netstat -tlnp | grep 8100 netstat -anp | grep 8100从输出可以发现有一个特殊的101我们用正常的进程看一般都是0。这个参数叫backlog表示连接等待队列的长度对应tomcat的acceptCount参数默认是100。当连接超过这个值时就会报connection reset by peer我们当前是101所以新来的请求就被拒绝了。tomcat线程模型对于第二个问题tomcat线程正在干什么。一般我们可以通过jstack pid导出线程堆栈分析不过当我们的服务运行一段时间例如好几天后执行jstackjmap都会报错似乎是某些信息被系统清除掉这点我还找到根本原因如果你知道答案请告知我一下。幸好有arthas我们可以通过thread命令查看线程和其堆栈信息。thread -n 10 #top 10 cpu thread 1 #展示线程1的堆栈 thread --all #展示所有线程 thread --all | grep http #展示http线程我们可以看到tomcat的10个核心线程还是在的且处于waitting状态。处于waitting状态是因为它在等任务执行从堆栈可以看出是阻塞在TaskQueue.take方法org.apache.tomcat.util.threads.TaskQueue是tomcat中的LinkedBlockingQueue是生产者-消费者模型take方法阻塞表示当前队列是空的没有任务需要执行一旦有任务放入TaskQueuetake方法就会唤醒进入Runnable状态。这点就很奇怪了前面说连接队列都满了但tomcat任务队列确是空的执行线程都处于等待任务状态一边满载一边空闲。要搞清楚这个问题需要我们对tomcat线程模型有所了解。tomcat支持几种IO模型BIO、NIO、AIO(NIO2)、APR我们可以通过server.tomcat.protocol参数进行设置默认用的是NIONIO是一种同步非阻塞IO。NIO的核心目的是可以用少量线程处理大量连接在linux用select/poll/epoll实现。NIO在很多中间件都有应用kafka,redis,rocketmq,gateway等等可以说涉及到网络处理的都离不开NIO。AIO是真正的异步IO但Linux对其支持不够完善且NIO已经足够高效所以NIO用得最多。reactor模型如何更好的实现NIO是个问题就好像我们实现某个功能要用到设计模式一样reactor就是NIO一种实现模式。doug lee在scalable io in java总结了3种模型单reactor单线程整个过程由一个线程完成包括创建连接读写数据业务处理。redis 6.0以前的版本就是这种模式实现起来简单没有线程切换加锁的开销。缺点是单线程不能发挥多核cpu的优势如果有一个业务处理阻塞了那么整个服务都会阻塞。单reactor多线程接收连接(accept)和IO读写还是由一个线程完成但业务处理会提交给业务线程池业务处理不会阻塞整个服务。多reactor多线程接收连接由一个main reactor处理建立连接后将其注册到sub reactor上每个sub reactor都是单reactor多线程模式。tomcat的实现tomcat的NIO由3种线程实现分别是Acceptor线程、Poller线程、请求处理线程。对于请求处理线程池我们比较熟悉常用的两个参数server.tomcat.minSpareThreads 10 server.tomcat.maxThreads 200对应到reactor模型可以看成它是一种多reactor多线程模型Acceptor线程负责建立连接然后将建立好的连接注册到Poller由Poller进行读写。Poller读写后创建请求将其交给请求处理线程池。Acceptor和Poller线程对应的run方法都是一个死循环源源不断的接收连接、读写连接。从reactor模型上看在多核cpu下多reactor多线程模型可以获得更高的效率但tomcat10以下默认只能有一个Acceptor和一个Poller线程。