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