排查和解决线程池瓶颈问题案例

在分布式系统中，线程池的使用非常普遍，尤其是在处理异步任务时。然而，线程池的配置不当可能会导致性能瓶颈，进而影响系统的整体性能。本文将分享一个实际案例，介绍如何通过日志分析和线程池优化来解决系统中的性能瓶颈问题。

问题背景

在我们的系统中，有一个基于Spring的事件监听机制，用于处理长连接消息的回调。事件监听器RawMessageEventListener通过onApplicationEvent方法处理事件。默认情况下，onApplicationEvent是同步执行的，但为了提升性能，我们使用了@Async注解将其改为异步执行。异步任务默认使用threadPoolTaskScheduler线程池。

在某天的10点左右，我们注意到系统的响应速度变慢，通过日志分析发现，threadPoolTaskScheduler线程池的处理能力成为了瓶颈。

问题排查

日志分析

首先，我们通过以下命令对日志进行分析：

tail -10000000 info-2025-02-23.log | grep '2025-02-23 10:' | grep 'threadPoolTaskScheduler' | awk '{print $4}' | sort | uniq -c

输出结果如下：

46586 [threadPoolTaskScheduler-1]

从日志中可以看到，在10点这个时间段内，threadPoolTaskScheduler线程池处理了4万多条日志，但只有一个线程在工作。这表明线程池的默认配置可能不足以应对高并发场景。

代码分析

我们进一步查看了事件监听器的代码：

@Async
public void onApplicationEvent(RawMessageEvent event) {// 处理事件逻辑ThreadPoolManager.getInstance().execute(() -> robotCallBackService.callBack(socketId, request, url));
}

@Async注解默认使用threadPoolTaskScheduler线程池，而该线程池的默认线程数为1。这意味着所有异步任务都会排队等待执行，导致任务积压，进而影响系统性能。

解决方案

增加线程池线程数

为了解决这个问题，我们决定自定义threadPoolTaskScheduler的配置，增加线程池的线程数。我们创建了一个配置类，设置了10个线程：

@Configuration
public class SchedulerConfig {@Beanpublic ThreadPoolTaskScheduler threadPoolTaskScheduler() {ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();scheduler.setPoolSize(10);scheduler.setThreadNamePrefix("CustomTaskScheduler-");return scheduler;}
}