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-";

        @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的动态全局线程池，后续改造吧

写到最后