作者：vivo 互聯網服務器團隊- Zhi Guangquan

HttpClient作為Java程序員最常用的Http工具，其對Http連接的管理能簡化開發，并且提升連接重用效率；在正常情況下，HttpClient能幫助我們高效管理連接，但在一些并發高，報文體較大的情況下，如果再遇到網絡波動，如何保證連接被高效利用，有哪些優化空間。

一、問題現象

北京時間X月X日，瀏覽器信息流服務監控出現異常，主要表現在以下三個方面：

1.從某個時間點開始，云監控顯示部分Http接口的熔斷器被打開，而且從明細列表可以發現問題機器：

2. 從PAAS平臺Hystrix熔斷管理界面中可以進一步確認問題機器的所有Http接口調用均出現了熔斷：

3. 日志中心有大量從Http連接池獲取連接的異常：

org.apache.http.impl.execchain.RequestAbortedException: Request aborted。

二、問題定位

綜合以上三個現象，大概可以推測出問題機器的TCP連接管理出了問題，可能是虛擬機問題，也可能是物理機問題；與運維與系統側溝通后，發現虛擬機與物理機均無明顯異常，第一時間聯系運維重啟了問題機器，線上問題得到解決。

2.1 臨時解決方案

幾天以后，線上部分其他機器也陸續出現了上述現象，此時基本可以確認是服務本身有問題；既然問題與TCP連接相關，于是聯系運維在問題機器上建立了一個作業查看TCP連接的狀態分布：

netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'

結果如下：

如上圖，問題機器的CLOSE_WAIT狀態的連接數已經接近200左右（該服務Http連接池最大連接數設置的250），那問題直接原因基本可以確認是CLOSE_WAIT狀態的連接過多導致的；本著第一時間先解決線上問題的原則，先把連接池調整到500，然后讓運維重啟了機器，線上問題暫時得到解決。

2.2 原因分析

調整連接池大小只是暫時解決了線上問題，但是具體原因還不確定，按照以往經驗，出現連接無法正常釋放基本都是開發者使用不當，在使用完成后沒有及時關閉連接；但很快這個想法就被否定了，原因顯而易見：當前的服務已經在線上運行了一周左右，中間沒有經歷過發版，以瀏覽器的業務量，如果是連接使用完沒有及時關。

閉，250的連接數連一分鐘都撐不到就會被打爆。那么問題就只能是一些異常場景導致的連接沒有釋放；于是，重點排查了下近期上線的業務接口，尤其是那種數據包體較大，響應時間較長的接口，最終把目標鎖定在了某個詳情頁優化接口上；先查看處于CLOSE_WAIT狀態的IP與端口連接對，確認對方服務器IP地址。

netstat-tulnap|grep CLOSE_WAIT

經過與合作方確認，目標IP均來自該合作方，與我們的推測是相符的。

2.3 TCP抓包

在定位問題的同時，也讓運維同事幫忙抓取了TCP的數據包，結果表明確實是客戶端（瀏覽器服務端）沒返回ACK結束握手，導致揮手失敗，客戶端處于了CLOSE_WAIT狀態，數據包的大小也與懷疑的問題接口相符。

為了方便大家理解，我從網上找了一張圖，大家可以作為參考：

CLOSE_WAIT是一種被動關閉狀態，如果是SERVER主動斷開的連接，那么就會在CLIENT出現CLOSE_WAIT的狀態，反之同理；

通常情況下，如果客戶端在一次http請求完成后沒有及時關閉流（tcp中的流套接字），那么超時后服務端就會主動發送關閉連接的FIN，客戶端沒有主動關閉，所以就停留在了CLOSE_WAIT狀態，如果是這種情況，很快連接池中的連接就會被耗盡。

所以，我們今天遇到的情況（處于CLOSE_WAIT狀態的連接數每天都在緩慢增長），更像是某一種異常場景導致的連接沒有關閉。

2.4 獨立連接池

為了不影響其他業務場景，防止出現系統性風險，我們先把問題接口連接池進行了獨立管理。

2.5 深入分析

帶著2.3的疑問我們仔細查看一下業務調用代碼：

try {httpResponse = HttpsClientUtil.getHttpClient().execute(request);HttpEntity httpEntity = httpResponse.getEntity();is = httpEntity.getContent();}catch (Exception e){log.error("");}finally {IOUtils.closeQuietly(is);IOUtils.closeQuietly(httpResponse);}

這段代碼存在一個明顯的問題：既關閉了數據傳輸流（?IOUtils.closeQuietly(is)），也關閉了整個連接（IOUtils.closeQuietly(httpResponse)），這樣我們就沒辦法進行連接的復用了；但是卻更讓人疑惑了：既然每次都手動關閉了連接，為什么還會有大量CLOSE_WAIT狀態的連接存在呢？

如果問題不在業務調用代碼上，那么只能是這個業務接口具有的某種特殊性導致了問題的發生；通過抓包分析發現該接口有一個明顯特征：接口返回報文較大，平均在500KB左右。那么問題就極有可能是報文過大導致了某種異常，造成了連接不能被復用也不能被釋放。

2.6 源碼分析

開始分析之前，我們需要了解一個基礎知識：Http的長連接和短連接。所謂長連接就是建立起連接之后，可以復用連接多次進行數據傳輸；而短連接則是每次都需要重新建立連接再進行數據傳輸。

而通過對接口的抓包我們發現，響應頭里有Connection:keep-live字樣，那我們就可以重點從HttpClient對長連接的管理入手來進行代碼分析。

2.6.1 連接池初始化

初始化方法：

進入PoolingHttpClientConnectionManager這個類，有一個重載構造方法里包含連接存活時間參數：

順著繼續向下查看：

manager的構造方法到此結束，我們不難發現validityDeadline會被賦值給expiry變量，那我們接下來就要看下HttpClient是在哪里使用expiry這個參數的；

通常情況下，實例對象被構建出來的時候會初始化一些策略參數，此時我們需要查看構建HttpClient實例的方法來尋找答案：

此方法包含一系列的初始化操作，包括構建連接池，給連接池設置最大連接數，指定重用策略和長連接策略等，這里我們還注意到，HttpClient創建了一個異步線程，去監聽清理空閑連接。

當然，前提是你打開了自動清理空閑連接的配置，默認是關閉的。

接著我們就看到了HttpClient關閉空閑連接的具體實現，里面有我們想要看到的內容：

此時，我們可以得出第一個結論：可以在初始化連接池的時候，通過實現帶參的PoolingHttpClientConnectionManager構造方法，修改validityDeadline的值，從而影響HttpClient對長連接的管理策略。

2.6.2 執行方法入口

先找到執行入口方法：

org.apache.http.impl.execchain.MainClientExec.execute,看到了keepalive相關代碼實現：

我們來看下默認的策略：

由于中間的調用邏輯比較簡單，就不在這里一一把調用的鏈路貼出來了，這邊直接給結論：HttpClient對沒有指定連接有效時間的長連接，有效期設置為永久（Long.MAX_VALUE）。

綜合以上分析,我們可以得出最終結論：

HttpClient通過控制newExpiry和validityDeadline來實現對長連接的有效期的管理，而且對沒有指定連接有效時間的長連接，有效期設置為永久。

至此我們可以大膽給出一個猜測：長連接的有效期是永久，而因為某種異常導致長連接沒有被及時關閉，而永久存活了下來，不能被復用也不能被釋放。（只是根據現象的猜測，雖然最后被證實并不完全正確，但確實提高了我們解決問題的效率）。

基于此，我們也可以通過改變這兩個參數來實現對長連接的管理：

這樣簡單修改上線后，處于close_wait狀態的連接數沒有再持續增長，這個線上問題也算是得到了徹底的解決。

但此時相信大家也都存在一個疑問：作為被廣泛使用的開源框架，HttpClient難道對長連接的管理這么粗糙嗎？一個簡單的異常調用就能導致整個調度機制徹底崩潰，而且不會自行恢復；

于是帶著疑問，再一次詳細查看了HttpClient的源碼。

三、關于HttpClient

3.1 前言

開始分析之前，先簡單介紹下幾個核心類：

• 1.【PoolingHttpClientConnectionManager】：連接池管理器類，主要作用是管理連接和連接池，封裝連接的創建、狀態流轉以及連接池的相關操作，是操作連接和連接池的入口方法；

• 2.【CPool】：連接池的具體實現類，連接和連接池的具體實現均在CPool以及抽象類AbstractConnPool中實現，也是分析的重點；

• 3.【CPoolEntry】：具體的連接封裝類，包含連接的一些基礎屬性和基礎操作，比如連接id，創建時間，有效期等；

• 4.【HttpClientBuilder】：HttpClient的構造器，重點關注build方法；

• 5.【MainClientExec】：客戶端請求的執行類，是執行的入口，重點關注execute方法；

• 6.【ConnectionHolder】：主要封裝釋放連接的方法，是在PoolingHttpClientConnectionManager的基礎上進行了封裝。

3.2 兩個連接

• 最大連接數（maxTotal）

• 最大單路由連接數(maxPerRoute)

• 1.最大連接數，顧名思義，就是連接池允許創建的最大連接數量；
  

• 2.最大單路由連接數可以理解為同一個域名允許的最大連接數，且所有maxPerRoute的總和不能超過maxTotal。

  以瀏覽器為例，瀏覽器對接了頭條和一點，為了做到業務隔離，不相互影響，可以把maxTotal設置成500，而defaultMaxPerRoute設置成400，主要是因為頭條的業務接口量遠大于一點，defaultMaxPerRoute需要滿足調用量較大的一方。

3.3 三個超時

• connectionRequestTimout

• connetionTimeout

• socketTimeout

【connectionRequestTimout】：指從連接池獲取連接的超時時間；

【connetionTimeout】：指客戶端和服務器建立連接的超時時間，超時后會報

ConnectionTimeOutException異常；

【socketTimeout】：指客戶端和服務器建立連接后，數據傳輸過程中數據包之間間隔的最大時間，超出后會拋出SocketTimeOutException。

一定要注意：這里的超時不是數據傳輸完成，而只是接收到兩個數據包的間隔時間，這也是很多線上詭異問題發生的根本原因。

3.4 四個容器

• free

• leased

• pending

• available

【free】：空閑連接的容器，連接還沒有建立，理論上freeSize=maxTotal -leasedSize

- availableSize（其實HttpClient中并沒有該容器，只是為了描述方便，特意引入的一個容器）。

【leased】：租賃連接的容器，連接創建后，會從free容器轉移到leased容器；也可以直接從available容器租賃連接，租賃成功后連接被放在leased容器中，此種場景主要是連接的復用，也是連接池的一個很重要的能力。

【pending】：等待連接的容器，其實該容器只是在等待連接釋放的時候用作阻塞線程，下文也不會再提到，感興趣的可以參考具體實現代碼，其與connectionRequestTimout相關。

【available】：可復用連接的容器，通常直接從leased容器轉移過來，長連接的情況下完成通信后，會把連接放到available列表，一些對連接的管理和釋放通常都是圍繞該容器進行的。

注：由于存在maxTotal和maxPerRoute兩個連接數限制，下文在提到這四種容器時，如果沒有帶前綴，都代表是總連接數，如果是r.xxxx則代表是路由連接里的某個容器大小。

maxTotal的組成

3.5 連接的產生與管理

1.循環從available容器中獲取連接，如果該連接未失效（根據上文提到的expiry字段判斷），則把該連接從available容器中刪除，并添加到leased容器，并返回該連接；

2.如果在第一步中沒有獲取到可用連接，則判斷r.available + r.leased是否大于maxPerRoute，其實就是判斷是否還有free連接；如果不存在，則需要把多余分配的連接釋放掉（r. available + r.leased - maxPerRoute），來保證真實的連接數受maxPerRoute控制（至于為什么會出現r.leased+r.available>maxPerRoute的情況其實也很好理解，雖然在整個狀態流轉過程都加了鎖，但是狀態的流轉并不是原子操作，存在一些異常的場景都會導致狀態短時間不正確）；所以我們可以得出結論，maxPerRoute只是一個理論上的最大數值，其實真實產生的連接數在短時間內是可能大于這個值的；

3.在真實的連接數（r .leased+ r .available）小于maxPerRoute且maxTotal>leased的情況下：如果free>0，則重新創建一個連接；如果free=0，則把available容器里的最早創建的一個連接關閉掉，然后再重新創建一個連接；看起來有點繞，其實就是優先使用free容器里的連接，獲取不到再釋放available容器里的連接；

4.如果經過上述過程仍然沒有獲取到可用連接，那就只能等待一個connectionRequestTimout時間，或者有其他線程的信號通知來結束整個獲取連接的過程。

3.6 連接的釋放

1.如果是長連接（reusable），則把該連接從leased容器中刪除，然后添加到available容器的頭部，設置有效期為expiry；

2.如果是短連接（non-reusable），則直接關閉該連接，并且從released容器中刪除，此時的連接被釋放，處于free容器中；

3.最后，喚醒“連接的產生與管理“第四部中的等待線程。

整個過程分析完，了解了httpclient如何管理連接，再回頭來看我們遇到的那個問題就比較清晰了：

正常情況下，雖然建立了長連接，但是我們會在finally代碼塊里去手動關閉，此場景其實是觸發了“連接的釋放”中的步驟2，連接直接被關閉；所以正常情況下是沒有問題的，長連接其實并沒有發揮真正的作用；

那問題自然就只能出現在一些異常場景，導致了長連接沒有被及時關閉，結合最初的分析，是服務端主動斷開了連接，那大概率出現在一些超時導致連接斷開的異常場景，我們再回到

org.apache.http.impl.execchain.MainClientExec這個類，發現這樣幾行代碼：

connHolder.releaseConnection()對應“連接的釋放”中提到的步驟1，此時連接只是被放入了available容器，并且有效期是永久；

return new HttpResponseProxy(response, null)返回的ConnectionHolder是null，結合IOUtils.closeQuietly(httpResponse)的具體實現，連接并沒有及時關閉，而是永久的放在了available容器里，并且狀態為CLOSE_WAIT，無法被復用；

根據 “連接的產生與管理”的步驟3的描述，在free容器為空的時候httpclient是能夠主動釋放available里的連接的，即使連接永久的放在了available容器里，理論上也不會造成連接永遠無法釋放；

然而再結合“連接的產生與管理”的步驟4，當free容器為空了以后，從連接池獲取連接時需要等待available容器里的連接被釋放掉，整個過程是單線程的，效率極低，勢必會造成擁堵，最終導致大量等待獲取連接超時報錯，這也與我們線上看到的場景相吻合。

四、總結

連接池的主要功能有兩個：連接的管理和連接的復用，在使用連接池的時候一定要注意只需關閉當前數據流，而不要每次都關閉連接，除非你的目標訪問地址是完全隨機的；

maxTotal和maxPerRoute的設置一定要謹慎，合理的分配參數可以做到業務隔離，但如果無法準確做出評估，可以暫時設置成一樣，或者用兩個獨立的httpclient實例；

一定記得要設置長連接的有效期，用

PoolingHttpClientConnectionManager(60, TimeUnit.SECONDS)構造函數，尤其是調用量較大的情況，防止發生不可預知的問題；

可以通過設置evictIdleConnections(5, TimeUnit.SECONDS)定時清理空閑連接，尤其是http接口響應時間短，并發量大的情況下，及時清理空閑連接，避免從連接池獲取連接的時候發現連接過期再去關閉連接，能在一定程度上提高接口性能。

五、寫在最后

HttpClient作為當前使用最廣泛的基于Java語言的Http調用框架，在筆者看來其存在兩點明顯不足：

沒有提供監控連接狀態的入口，也沒有提供能外部介入動態影響連接生命周期的擴展點，一旦線上出現問題可能就是致命的；

此外，其獲取連接的方式是采用同步鎖的方式，在并發較高的情況下存在一定的性能瓶頸，而且其對長連接的管理方式存在問題，稍不注意就會導致建立大量異常長連接而無法及時釋放，造成系統性災難。

END

—— 活動推薦——

參考閱讀：

• B站云原生混部技術實踐

• 會員服務優雅上下線實踐

• 可視化服務編排在金融APP中的實踐

• 長路漫漫, 從Blink-tree 到Bw-tree (上)

• Redis 定長隊列的探索和實踐

本文由高可用架構轉載。技術原創及架構實踐文章，歡迎通過公眾號菜單「聯系我們」進行投稿。

總結

以上是生活随笔為你收集整理的HttpClient 在vivo内销浏览器的高并发实践优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。