Spring Boot 3.4 集成阿里云 PAI-EAS 出現(xiàn)連接池耗盡問題的排查與修復(fù)昨天凌晨兩點監(jiān)控平臺突然告警生產(chǎn)環(huán)境的 AI 推理服務(wù)響應(yīng)時間從正常的 200ms 飆升到 5000ms隨后大量請求直接超時。查看應(yīng)用日志滿屏都是org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection from pool。這個異常非常典型通常意味著 HTTP 連接池被占滿且無法釋放。當(dāng)時項目正在對接阿里云 PAI-EAS 模型在線服務(wù)業(yè)務(wù)量激增觸發(fā)了這個隱藏極深的資源泄漏問題。這個問題之所以難排查是因為它在低并發(fā)測試環(huán)境下完全不會復(fù)現(xiàn)。只有當(dāng) QPS 超過一定閾值且部分請求因網(wǎng)絡(luò)波動或模型推理耗時較長時連接池才會迅速枯竭。官方文檔雖然推薦直接使用RestTemplate或WebClient的默認配置但在我們這種高并發(fā)、長連接的 AI 推理場景下默認配置反而成了性能瓶頸。環(huán)境準(zhǔn)備本次排查基于生產(chǎn)環(huán)境實際配置確保讀者可以復(fù)現(xiàn)同樣的問題場景。JDK 版本: 21.0.2 LTSSpring Boot 版本: 3.4.0HTTP 客戶端: Apache HttpClient 5.3.1 (Spring Boot 3.4 默認不再包含需顯式引入)阿里云 SDK: alibabacloud-pai-eas 2.0.1操作系統(tǒng): Linux Kernel 5.15.0在pom.xml中除了常規(guī)的 Spring Boot Starter 外必須顯式引入 HttpClient 5 的依賴否則 Spring Boot 3.4 可能會回退到舊版客戶端或?qū)е骂惣虞d沖突。xmlorg.springframework.bootspring-boot-starter-weborg.apache.httpcomponents.client5httpclient55.3.1核心步驟1. 復(fù)現(xiàn)連接池耗盡場景為了定位問題首先需要在本地模擬高并發(fā)請求。使用 JMH 或簡單的線程池模擬 200 個并發(fā)線程同時調(diào)用 PAI-EAS 的推理接口。默認情況下Spring Boot 創(chuàng)建的RestTemplate使用的是SimpleClientHttpRequestFactory它每次請求都會新建連接或者使用連接池配置極小的HttpComponentsClientHttpRequestFactory。在 200 并發(fā)下默認連接池上限通常為 20總連接數(shù)上限為 200。一旦有部分請求處理時間超過 5 秒新請求就會因為拿不到連接而拋出ConnectionPoolTimeoutException。2. 分析根因生命周期不匹配排查過程中發(fā)現(xiàn)問題不僅僅在于連接數(shù)配置。更深層的原因是PoolingHttpClientConnectionManager的生命周期管理不當(dāng)。很多開發(fā)者習(xí)慣在Bean方法中直接 new 一個連接管理器但這會導(dǎo)致連接池?zé)o法優(yōu)雅關(guān)閉且無法動態(tài)調(diào)整路由參數(shù)。另一個被忽視的細節(jié)是 PAI-EAS 服務(wù)的 Keep-Alive 策略。模型推理服務(wù)通常傾向于保持長連接以減少握手開銷但如果后端客戶端不主動回收空閑連接空閑連接會一直占用池資源直到超時。3. 實施修復(fù)方案修復(fù)的核心在于顯式配置PoolingHttpClientConnectionManager并設(shè)置合理的MaxConnTotal和MaxConnPerRoute。同時必須開啟連接回收機制定期清理空閑連接。javaConfigurationpublic class HttpClientConfig {Beanpublic PoolingHttpClientConnectionManager connectionManager() {PoolingHttpClientConnectionManager manager new PoolingHttpClientConnectionManager();// 全局最大連接數(shù)根據(jù)業(yè)務(wù) QPS 和平均響應(yīng)時間計算manager.setMaxTotal(500);// 單路由最大連接數(shù)PAI-EAS 通常只有一個 endpointmanager.setDefaultMaxPerRoute(200);return manager;}Beanpublic CloseableHttpClient httpClient(PoolingHttpClientConnectionManager manager) {return HttpClientBuilder.create().setConnectionManager(manager).setDefaultRequestConfig(RequestConfig.custom().setConnectTimeout(5, TimeUnit.SECONDS).setConnectionRequestTimeout(5, TimeUnit.SECONDS).setSocketTimeout(60, TimeUnit.SECONDS).build()).build();}Beanpublic RestTemplate restTemplate(CloseableHttpClient httpClient) {HttpComponentsClientHttpRequestFactory factory new HttpComponentsClientHttpRequestFactory(httpClient);factory.setReadTimeout(60000);return new RestTemplate(factory);}}此外必須引入連接回收線程。這是官方文檔中容易遺漏的部分。如果不啟動回收線程連接池中的空閑連接不會自動釋放導(dǎo)致高并發(fā)后連接數(shù)居高不下。javaPostConstructpublic void init() {// 每 30 秒回收一次空閑連接Timer timer new Timer();timer.scheduleAtFixedRate(new TimerTask() {Overridepublic void run() {connectionManager.closeIdleConnections(30, TimeUnit.SECONDS);connectionManager.closeExpiredConnections();}}, 30000, 30000);}驗證與常見問題修復(fù)完成后再次進行 500 并發(fā)壓測。觀察JVM的線程狀態(tài)和網(wǎng)絡(luò)連接數(shù)連接池不再出現(xiàn)Timeout異常。平均響應(yīng)時間穩(wěn)定在 300ms 以內(nèi)P99 延遲控制在 1.2s 左右。| 配置項 | 默認配置表現(xiàn) | 優(yōu)化后配置表現(xiàn) | 說明 || :--- | :--- | :--- | :--- || 最大連接數(shù) (MaxTotal) | 20 | 500 | 默認值過小無法支撐高并發(fā) || 單路由連接數(shù) (MaxPerRoute) | 20 | 200 | 針對單一 AI 服務(wù)端點需調(diào)大 || 連接超時時間 (ConnectTimeout) | 默認 5s | 5s | 保持短超時快速失敗 || 空閑連接回收 | 無 | 每 30s 回收 | 防止連接泄漏和僵尸連接 |常見問題中還有一個容易被忽略的點HttpClient實例必須是單例的。如果在每個 Controller 方法中都 new 一個HttpClient會導(dǎo)致線程數(shù)爆炸和端口耗盡。務(wù)必確保CloseableHttpClient作為 Spring Bean 被管理。另外有開發(fā)者嘗試通過增加MaxConnTotal到 10000 來解決超時這個方案雖然官方推薦但在我們場景下反而更糟。過大的連接數(shù)會導(dǎo)致 TCP 握手風(fēng)暴觸發(fā)阿里云端限流最終導(dǎo)致整體服務(wù)不可用。合理的數(shù)值應(yīng)該基于QPS * 平均響應(yīng)時間來估算?？偨Y(jié)對接阿里云 PAI-EAS 這類 AI 推理服務(wù)時不能簡單套用 Web 服務(wù)的 HTTP 配置。模型推理的耗時特性要求客戶端具備更穩(wěn)健的連接管理能力。顯式配置連接池、啟用空閑連接回收、確保 HttpClient 單例化是避免生產(chǎn)環(huán)境連接池耗盡的三道防線。默認配置往往是為了通用場景設(shè)計的在高并發(fā)垂直場景下必須根據(jù)實際業(yè)務(wù)指標(biāo)進行調(diào)優(yōu)。#后端 #Java #SpringBoot #阿里云 #HttpClient你在實際項目中有遇到類似問題嗎歡迎在評論區(qū)分享你的經(jīng)驗和解決方案。