记一次生产环境 tomcat 线程数打满情况分析

• 前言旨在分享工作中遇到的各种问题及解决思路与方案,与大家一起学习.-- 学无止境, 加油 ! Just do it !



• 问题描述运行环境描述tomcat-8.5单节点(该应用集群20个节点) avg-tps 250,max-tps 350tomcat max-threads:200 (下图蓝色线)tomcat busy-threads 正常(下图绿色线)tomcat cur-threads飞升(下图黄色线)每次黄色线上升时可以发现原本平均响应时间100ms内的接口响应时间均在3-10s

• 



• 原因分析 线程问题首先来一波jstack

• 上图是当时某个节点线程飙升时dump下来的线程日志,在这个时间点的线程中有大量的TIMED_WAITING 状态,可以先复习一波线程状态了,走起.

• 

• 很明显可以看到堆中的大对象内容,结合实际业务可以准确定位需要优化的接口了,那么cur-threads线程数为什么一直增长呢?为什么不回收呢?带着这两个疑问,我们先去找下tomcat官网针对这两个参数的描述;

• 

• 上图可以看到最大线程数默认是200,初始化空闲线程数10,与我们线上环境一致(附上图中tomcat资料链接)

• 

• 上图也是找的tomcat官网(附上图中tomcat资料),第三个参数 maxIdleTime 线程闲置一分钟后会被回收



• 总结cur-threads一直增长的原因接口并发且发生了大量缓存穿透(线程日志中大量time_wait线程是项目中防缓存穿透使用的锁),造成锁等待,进而造成tomcat当前线程不够用,所以cur线程数据增加,每次在线程数增加的时候接口响应均达到秒级别,可能创建Thread比较消耗资源,这块有待验证!tomcat线程一直不回收的原因Tomcat线程池每次从队列头部取线程去处理请求，请求完结束后再放到队列尾部,在高并发下,每个线程都会在短时间内被使用,达不到1分钟空闲被回收的条件

• 解决方案与建议 需要优化响应慢的接口(治本)如果可以,降低接口并发(治标)适当增加tomcat的maxThreads值可以提升应用性能(不是越大越好，最优配置数值需要模拟pro环境经过大量压测对比得出)

• 优化后

• 

• 本次改造有两个点

• 上图是在改造后的第二天可以明显看到cur线程数有一个下降,基本验证思路正确.



欢迎关注个人订阅号:Java技术宝典 ,及时获取最新分享.