在分布式系統中，線程池的使用非常普遍，尤其是在處理異步任務時。然而，線程池的配置不當可能會導致性能瓶頸，進而影響系統的整體性能。本文將分享一個實際案例，介紹如何通過日志分析和線程池優化來解決系統中的性能瓶頸問題。

問題背景

在我們的系統中，有一個基于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;}
}

通過這個配置，我們為threadPoolTaskScheduler線程池設置了10個線程，從而提升了并發處理能力。

驗證效果

在應用了新的線程池配置后，我們再次觀察系統的日志和性能。發現threadPoolTaskScheduler線程池能夠同時處理多個任務，系統的響應速度明顯提升，任務積壓的問題得到了有效緩解。

結論

通過這次排查和優化，我們認識到線程池的配置對系統性能有著重要影響。在高并發場景下，默認的線程池配置可能無法滿足需求，因此需要根據實際情況進行調整。通過自定義線程池配置，我們成功解決了系統中的性能瓶頸問題。

關鍵點總結

1. 日志分析：通過日志分析發現線程池的瓶頸。
2. 代碼審查：確認@Async注解默認使用的線程池配置。
3. 自定義線程池：通過自定義配置增加線程池的線程數，提升并發處理能力。
4. 驗證效果：通過日志和性能監控驗證優化效果。

希望這個案例能夠幫助大家在遇到類似問題時，快速定位并解決問題。如果你有類似的經驗或其他優化方案，歡迎在評論區分享！