在高并发、异步化等场景，线程池的运用可以说无处不在。拉勾IT课小编为大家分解 
线程池从本质上来讲，即通过空间换取时间，因为线程的创建和销毁都是要消耗资源和时间的，对于大量使用线程的场景，使用池化管理可以延迟线程的销毁，大大提高单个线程的复用能力，进一步提升整体性能。 
今天遇到了一个比较典型的线上问题，刚好和线程池有关，另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点，同时整个调查思路可以借鉴，特此记录和分享一下。 
业务背景描述 
该线上问题发生在广告**的核心扣费服务，首先简单交代下大致的业务流程，方便理解问题。 
  
  
  
绿框部分即扣费服务在广告召回扣费流程中所处的位置，简单理解：当用户点击一个广告后，会从C端发起一次实时扣费请求(CPC，按点击扣费模式)，扣费服务则承接了该动作的核心业务逻辑：包括执行反作弊策略、创建扣费记录、click日志埋点等。 
问题现象和业务影响 
12月2号晚上11点左右，我们收到了一个线上告警通知：扣费服务的线程池任务队列大小远远超出了设定阈值，而且队列大小随着时间推移还在持续变大。详细告警内容如下： 
  
  
  
相应的，我们的广告指标：点击数、收入等也出现了非常明显的下滑，几乎同时发出了业务告警通知。其中，点击数指标对应的曲线表现如下： 
  
  
  
该线上故障发生在流量高峰期，持续了将近30分钟后才恢复正常。
联系我时，请说是在得易搜分类信息网看到的，谢谢！