在分布式系统中，线程池的使用非常普遍，尤其是在处理异步任务时。然而，线程池的配置不当可能会导致性能瓶颈，进而影响系统的整体性能。本文将分享一个实际案例，介绍如何通过日志分析和线程池优化来解决系统中的性能瓶颈问题。
问题背景
在我们的系统中，有一个基于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万多条日志，但只有一个线程在工作。这表明线程池的默认配置可能不足以应对高并发场景。
代码分析
我们进一步查看了事件监听器的代码：
java">@Async
public void onApplicationEvent(RawMessageEvent event) {
// 处理事件逻辑
ThreadPoolManager.getInstance().execute(() -> robotCallBackService.callBack(socketId, request, url));
}
@Async注解默认使用threadPoolTaskScheduler线程池，而该线程池的默认线程数为1。这意味着所有异步任务都会排队等待执行，导致任务积压，进而影响系统性能。
解决方案
增加线程池线程数
为了解决这个问题，我们决定自定义threadPoolTaskScheduler的配置，增加线程池的线程数。我们创建了一个配置类，设置了10个线程：
java">@Configuration
public class SchedulerConfig {
@Bean
public ThreadPoolTaskScheduler threadPoolTaskScheduler() {
ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
scheduler.setPoolSize(10);
scheduler.setThreadNamePrefix("CustomTaskScheduler-");
return scheduler;
}
}
通过这个配置，我们为threadPoolTaskScheduler线程池设置了10个线程，从而提升了并发处理能力。
验证效果
在应用了新的线程池配置后，我们再次观察系统的日志和性能。发现threadPoolTaskScheduler线程池能够同时处理多个任务，系统的响应速度明显提升，任务积压的问题得到了有效缓解。
结论
通过这次排查和优化，我们认识到线程池的配置对系统性能有着重要影响。在高并发场景下，默认的线程池配置可能无法满足需求，因此需要根据实际情况进行调整。通过自定义线程池配置，我们成功解决了系统中的性能瓶颈问题。
关键点总结
- 日志分析：通过日志分析发现线程池的瓶颈。
- 代码审查：确认
@Async注解默认使用的线程池配置。 - 自定义线程池：通过自定义配置增加线程池的线程数，提升并发处理能力。
- 验证效果：通过日志和性能监控验证优化效果。
希望这个案例能够帮助大家在遇到类似问题时，快速定位并解决问题。如果你有类似的经验或其他优化方案，欢迎在评论区分享！
