SkyWalking高频采集泄漏线程导致CPU满载排查思路
SkyWalking高频采集泄漏线程导致CPU满载排查思路
契机
最近在消除线上服务告警，发现Java线上测试服经常CPU满载告警，以前都是重启解决，今天好好研究下，打arthas火焰图发现是SkyWalking-agent的线程采集任务一直在吃cpu，jstack一看发现有1w+线程，故使用JProfiler好好排查了下，终于定位到了线程泄漏的原因。
收集线上信息
#找到异常程序，记录pid
top -c#进入arthas,并选择pid
java -jar arthas.jar#arthas控制台打火焰图
[arthas@x]$ profiler start
Profiling started（中间记录个30s）
[arthas@x]$ profiler stop
#大概知道线程有问题#查看服务此时线程数
ps -eLf | grep <service_name> | wc -l#dump下线程
jstack <pid> > thread-dump.txt#dump堆栈(对排查用处不大)
jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>
用JProfiler分析hprof
可以看到此时确实有1w2的存活线程
右键thread，查看是谁持有的thread，发现都是ThreadPoolExecutor基础线程池
同样去查看ThreadPoolExecutor的引用，此时发现差不到是谁声明的ThreadPoolExecutor，线索也就断了
分析jstack线程转储
使用jstack导出的txt，或者JProfiler的线程转储，信息都一样，发现都不能定位到线程/线程池是哪里来的，但是通过比较发现：线程命名太过于规范pool-367-thread-7，并且后缀不超过10，那么代表一定是我们显示的创建的ThreadPoolExecutor，并且制定了线程数=10。随后在代码中搜索线程池创建：ThreadPoolExecutor，newFixedThreadPool。发现确实有很多地方在声明，但是无法定位到具体代码
用JProfiler直接分析线上程序
这里需要提前使用命令行链接一下，不然会有known_hosts报错
此时在线程monitor里面就可以看到新线程创建的堆栈，马赛克就是我的业务代码
分析代码
发现是在方法中定义了ThreadPoolExecutor，但是没有调用shutdown方法来正确关闭。导致即使业务方法执行完成后，线程池依然存在，导致线程泄漏。业务中使用全局线程池！
/*** 重新定义线程名称，方便排查*/private final ThreadFactory namedThreadFactory = new ThreadFactory() {private final AtomicInteger threadNumber = new AtomicInteger(1);private final String namePrefix = "name-Thread-";@Overridepublic Thread newThread(Runnable r) {Thread t = new Thread(r, namePrefix + threadNumber.getAndIncrement());return t;}};private final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(10, 20, 5L, TimeUnit.MINUTES,new ArrayBlockingQueue<>(100), namedThreadFactory, new ThreadPoolExecutor.CallerRunsPolicy());
无法被回收原因
JAVA// ThreadPoolExecutor内部实现关键代码
private final class Workerextends AbstractQueuedSynchronizerimplements Runnable
{final Thread thread; // 工作线程持有Runnable引用Runnable firstTask;Worker(Runnable firstTask) {this.firstTask = firstTask;this.thread = getThreadFactory().newThread(this);}public void run() {runWorker(this); // 这里会产生循环引用}
}
无法回收的根本原因：
- 每个Worker线程通过
thread -> this（Worker实例）-> outerClass（ThreadPoolExecutor）形成引用闭环 - 即使外部没有引用，只要工作线程存活，就会保持对线程池的强引用
总结
- JProfiler可以远程分析线上程序
- 线程池无法被回收的本质原因是其内部的工作线程（Worker）与线程池实例之间的循环强引用，只有当工作线程完全终止（进入TERMINATED状态）且外部没有其他引用时，GC才能回收线程池实例。
- 应该使用github的动态全局线程池，后续改造吧
写到最后
