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-";
@Override
public 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 Worker
extends AbstractQueuedSynchronizer
implements 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的动态全局线程池,后续改造吧