通过一次生产case深入理解tomcat线程池

最近生产上遇到一个case，终于想明白了原因，今天周末来整理一下

生产case

最近测试istio mesh的预热功能(调用端最小连接数原则)

来控制调用端进入k8s刚扩出来的容器的流量

因为刚启动的JVM解释执会导致慢请求，如果不控制流量会导致cpu突然飙升等带来的一系列连锁反应！

表像这里我借用github上有个哥们的相类似提问：

翻译一下：

首先突发流量导致线程突然上升到最大线程（800），

流量下来后还在工作的线程(busy threads)线程就下降到了 10，

但是tomcat的 currentThreadCount 仍然是 800。

根据对于线程池的理解，tomcat的工作线程空闲 60 秒(默认)，它就会被回收呀，为啥一直下不来呢？

我和他只是配置有点不一样,表像是一样的，也是同样的疑问

问题重点

为什么流量下来后tomcat的工作线程居高不下迟迟得不到回收？
查文档或者搜google，都说设置maxIdleTime，其实它是有坑的

假设tomcat的配置如下(关键参数)：



 <!--The connectors can use a shared executor, you can define one or more named thread pools

   <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"

    maxThreads="150" minSpareThreads="4" maxIdleTime="60000"/>

  -->          

            

<Connector port="8080" 

          protocol="org.apache.coyote.http11.Http11NioProtocol"

          minSpareThreads="20"

          maxThreads="1024"

          maxConnections="10000" 

          connectionTimeout="60000" 

          acceptCount="150"/>

问题排查

根据tomcat源码

我们把上面几个核心参数都理一遍

acceptCount

TCP SYN QUEUE队列的长度默认 100

connectionTimeout

默认 20000ms

对应Socket的SO_TIMEOUT属性是用于指定 ServerSocket.accept 和 Socket.getInputStream().read 超时的套接字选项，超时会抛出SocketTimeoutException 【60000意味着如果超过1分钟还没有数据到达】

tomcat的核心流程

我们先讲讲下当请求进入，tomcat经历了哪些步骤：

tcp建立相关略

1)Acceptor线程处理 socket accept
2)Acceptor线程处理注册registered OP_READ到多路复用器
3)ClientPoller线程监听多路复用器的事件(OP_READ)触发
4)从tomcat的work线程池取一个工作线程来处理socket[http-nio-8080-exec-xx]

maxConnections

accptor线程和clientPoller线程的交互逻辑如下：

在这个交互中，每serverSock.accept()会被org.apache.tomcat.util.threads.LimitLatch计数在closeSocket的时候减少计数！

LimitLatch这个对象的计数初始值就是配置的maxConnections值（默认为10000）

minSpareThreads和maxThreads

minSpareThreads 核心线程数
maxThreads 最大线程数

ClientPoller线程拿到read或者write事件后进行处理就会从tomcat的线程池拿到一个工作线程去处理

这里的tomcat的Connector在创建工作线程池就会用到这2个参数

注意这里的线程池的keepAlivetime=60s

线程池相关知识（参考我之前的文章）

用一张图来表达各个参数的起作用点

梳理一下

当tomcat容器启动后

根据配置创建 acceptor线程池(默认1个) poller线程池(默认2个)

工作线程池(20个根据我的配置)

假设突发流量打进来，因为我设置的maxThreads=1024

那么会一直创建新的nio处理线程到1024

等后面流量下去了，由于线程的keepalivetime=60s

只要服务一直都有请求进来，

工作线程会从 queue 中抢任务，只要抢到了一个任务，它的 keepalivetime 就会重置

由于我的服务高峰过后，每分钟的请求数量大约是 3000 ~ 4000 个，也就是说每个线程都有机会抢到任务，这应该就是线程一直存活的原因

（当然了没有机会抢到任务的就回收了，所以也不会一直是1024）

第二个问题，既然这样我有办法修改工作线程的keepalivetime吗

可以的，但是得换成用Executor创建的线程池(如下我改成了10s)



 <!--The connectors can use a shared executor, you can define one or more named thread pools --> 

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"

    maxThreads="1024" minSpareThreads="20" maxIdleTime="10000"/>

          

            

<Connector port="8080" 

          protocol="org.apache.coyote.http11.Http11NioProtocol"

          executor="tomcatThreadPool"

          maxConnections="10000" 

          connectionTimeout="60000" 

          acceptCount="150"/>

如果你配置了Executor的话,那么Executor的创建线程池逻辑如下：

确认使用了maxIdleTime值来设置线程的keepalivetime

tomcat7配置解说官网：https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

tomcat8配置解说官网：https://tomcat.apache.org/tomcat-8.0-doc/config/http.html

注意的一点是，一定要却别理解Excutor和Connector两种在创建线程池是有区别的，不能混淆了

如果用Connector创建的线程池是写死60s！

由于tomcat默认都是不推荐使用共享的Executor(被注释的)，但是在Connector里面又不支持设置工作线程的maxIdleTime，这个有点不理解为什么这么设计！

总结

通过这个case，带着这些参数在tomcat里是怎么起作用的疑问，结合tomcat的源码，是次很有收获的梳理！