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

时间：2024-04-16 09:17:26

  • 前言

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

  • 问题描述

    • 运行环境描述

      • tomcat-8.5

      • 单节点(该应用集群20个节点) avg-tps 250,max-tps 350

      • tomcat max-threads:200 (下图蓝色线)

      • tomcat busy-threads 正常(下图绿色线)

      • tomcat cur-threads飞升(下图黄色线)

      • 每次黄色线上升时可以发现原本平均响应时间100ms内的接口响应时间均在3-10s 在这里插入图片描述

    • 提出问题

      使用grafana监控发现服务某个节点的cur线程数会暴涨直至Max-threads数且一直无法回收

    • 期望

      解决cur-threads回收问题,让线程正常回收

  • 原因分析

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

    • Java线程的5种状态

      • 新建状态(New): 线程对象被创建后，就进入了新建状态。例如，Thread thread = new Thread()。

      • 就绪状态(Runnable): 也被称为“可执行状态”。线程对象被创建后，其它线程调用了该对象的start()方法，从而来启动该线程。例如，thread.start()。处于就绪状态的线程，随时可能被CPU调度执行。

      • 运行状态(Running): 线程获取CPU权限进行执行。需要注意的是，线程只能从就绪状态进入到运行状态。

      • 阻塞状态(Blocked): 阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态，才有机会转到运行状态。阻塞的情况分三种：

        • 等待阻塞 -- 通过调用线程的wait()方法，让线程等待某工作的完成。

        • 同步阻塞 -- 线程在获取synchronized同步锁失败(因为锁被其它线程所占用)，它会进入同步阻塞状态。

        • 其他阻塞 -- 通过调用线程的sleep()或join()或发出了I/O请求时，线程会进入到阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

      • 死亡状态(Dead): 线程执行完了或者因异常退出了run()方法，该线程结束生命周期。 在这里插入图片描述

    • Jstack中常见的线程状态

      • RUNNABLE 线程运行中或I/O等待

      • BLOCKED 线程在等待monitor锁(synchronized关键字)

      • TIMED_WAITING 线程在等待唤醒，但设置了时限(lock.wait(10))

      • WAITING 线程在无限等待唤醒(lock.wait(10))

    复习完了,结合上面的线程日志以及服务中高并发的接口,找到有用到lock锁的接口,分析代码,到这一步基本算是找到解题思路了,如此多的线程等待是因为并发的查询接口缓存穿透了 接下来还要dump下这个节点的堆内存来具体分析,准确定位,下图是堆内存日志: 在这里插入图片描述 很明显可以看到堆中的大对象内容,结合实际业务可以准确定位需要优化的接口了,那么cur-threads线程数为什么一直增长呢?为什么不回收呢?带着这两个疑问,我们先去找下tomcat官网针对这两个参数的描述; 在这里插入图片描述

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

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

  • 总结

    • cur-threads一直增长的原因

      • 接口并发且发生了大量缓存穿透(线程日志中大量time_wait线程是项目中防缓存穿透使用的锁),造成锁等待,进而造成tomcat当前线程不够用,所以cur线程数据增加,每次在线程数增加的时候接口响应均达到秒级别,可能创建Thread比较消耗资源,这块有待验证!

    • tomcat线程一直不回收的原因

      • Tomcat线程池每次从队列头部取线程去处理请求，请求完结束后再放到队列尾部,在高并发下,每个线程都会在短时间内被使用,达不到1分钟空闲被回收的条件

  • 解决方案与建议

    • 需要优化响应慢的接口(治本)

    • 如果可以,降低接口并发(治标)

    • 适当增加tomcat的maxThreads值可以提升应用性能(不是越大越好，最优配置数值需要模拟pro环境经过大量压测对比得出)

  • 优化后

    在这里插入图片描述

  • 本次改造有两个点

    • 降低并发(比如serv A->serv-B,查询并发比较高,可以根据实际业务考虑在A系统做缓存,降低B系统并发)

    • 优化响应慢的接口 (如果业务复杂可以先考虑设计是否合理再考虑技术改造(多线程,缓存中间件))

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

 

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

相关文章