最近生产上遇到一个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的源码，是次很有收获的梳理！