?作者｜vivo 互聯(lián)網(wǎng)服務(wù)器團隊- Zhi Guangquan

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

一、問題現(xiàn)象

北京時間X月X日，瀏覽器信息流服務(wù)監(jiān)控出現(xiàn)異常，主要表現(xiàn)在以下三個方面：

從某個時間點開始，云監(jiān)控顯示部分Http接口的熔斷器被打開，而且從明細列表可以發(fā)現(xiàn)問題機器：

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

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

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

二、問題定位

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

2.1 臨時解決方案

幾天以后，線上部分其他機器也陸續(xù)出現(xiàn)了上述現(xiàn)象，此時基本可以確認是服務(wù)本身有問題；既然問題與TCP連接相關(guān)，于是聯(lián)系運維在問題機器上建立了一個作業(yè)查看TCP連接的狀態(tài)分布：

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

?結(jié)果如下：

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

2.2 原因分析

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

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

netstat-tulnap|grep CLOSE_WAIT

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

2.3 TCP抓包

在定位問題的同時，也讓運維同事幫忙抓取了TCP的數(shù)據(jù)包，結(jié)果表明確實是客戶端（瀏覽器服務(wù)端）沒返回ACK結(jié)束握手，導(dǎo)致?lián)]手失敗，客戶端處于了CLOSE_WAIT狀態(tài)，數(shù)據(jù)包的大小也與懷疑的問題接口相符。

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

CLOSE_WAIT是一種被動關(guān)閉狀態(tài)，如果是SERVER主動斷開的連接，那么就會在CLIENT出現(xiàn)CLOSE_WAIT的狀態(tài)，反之同理；

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

所以，我們今天遇到的情況（處于CLOSE_WAIT狀態(tài)的連接數(shù)每天都在緩慢增長），更像是某一種異常場景導(dǎo)致的連接沒有關(guān)閉。

2.4 獨立連接池

為了不影響其他業(yè)務(wù)場景，防止出現(xiàn)系統(tǒng)性風險，我們先把問題接口連接池進行了獨立管理。

2.5 深入分析

帶著2.3的疑問我們仔細查看一下業(yè)務(wù)調(diào)用代碼：

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);
     }

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

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

2.6 源碼分析

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

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

2.6.1 連接池初始化 

初始化方法：

進入PoolingHttpClientConnectionManager這個類，有一個重載構(gòu)造方法里包含連接存活時間參數(shù)：

順著繼續(xù)向下查看：

manager的構(gòu)造方法到此結(jié)束，我們不難發(fā)現(xiàn)validityDeadline會被賦值給expiry變量，那我們接下來就要看下HttpClient是在哪里使用expiry這個參數(shù)的；

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

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

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

接著我們就看到了HttpClient關(guān)閉空閑連接的具體實現(xiàn)，里面有我們想要看到的內(nèi)容：

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

2.6.2 執(zhí)行方法入口

先找到執(zhí)行入口方法：

org.apache.http.impl.execchain.MainClientExec.execute,看到了keepalive相關(guān)代碼實現(xiàn)：

我們來看下默認的策略：

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

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

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

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

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

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

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

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

三、關(guān)于HttpClient

3.1 前言

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

• 【PoolingHttpClientConnectionManager】：連接池管理器類，主要作用是管理連接和連接池，封裝連接的創(chuàng)建、狀態(tài)流轉(zhuǎn)以及連接池的相關(guān)操作，是操作連接和連接池的入口方法；
• 【CPool】：連接池的具體實現(xiàn)類，連接和連接池的具體實現(xiàn)均在CPool以及抽象類AbstractConnPool中實現(xiàn)，也是分析的重點；
• 【CPoolEntry】：具體的連接封裝類，包含連接的一些基礎(chǔ)屬性和基礎(chǔ)操作，比如連接id，創(chuàng)建時間，有效期等；
• 【HttpClientBuilder】：HttpClient的構(gòu)造器，重點關(guān)注build方法；
• 【MainClientExec】：客戶端請求的執(zhí)行類，是執(zhí)行的入口，重點關(guān)注execute方法；
• 【ConnectionHolder】：主要封裝釋放連接的方法，是在PoolingHttpClientConnectionManager的基礎(chǔ)上進行了封裝。

3.2 兩個連接

• 最大連接數(shù)（maxTotal）
• 最大單路由連接數(shù)(maxPerRoute)

• 最大連接數(shù)，顧名思義，就是連接池允許創(chuàng)建的最大連接數(shù)量；

• 最大單路由連接數(shù)可以理解為同一個域名允許的最大連接數(shù)，且所有maxPerRoute的總和不能超過maxTotal。以瀏覽器為例，瀏覽器對接了頭條和一點，為了做到業(yè)務(wù)隔離，不相互影響，可以把maxTotal設(shè)置成500，而defaultMaxPerRoute設(shè)置成400，主要是因為頭條的業(yè)務(wù)接口量遠大于一點，defaultMaxPerRoute需要滿足調(diào)用量較大的一方。

3.3 三個超時

• connectionRequestTimout
• connetionTimeout
• socketTimeout

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

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

• ConnectionTimeOutException異常；

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

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

3.4 四個容器

• free
• leased
• pending
• available

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

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

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

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

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

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

maxTotal的組成

3.5 連接的產(chǎn)生與管理

1. 循環(huán)從available容器中獲取連接，如果該連接未失效（根據(jù)上文提到的expiry字段判斷），則把該連接從available容器中刪除，并添加到leased容器，并返回該連接；
2. 如果在第一步中沒有獲取到可用連接，則判斷r.available + r.leased是否大于maxPerRoute，其實就是判斷是否還有free連接；如果不存在，則需要把多余分配的連接釋放掉（r. available + r.leased - maxPerRoute），來保證真實的連接數(shù)受maxPerRoute控制（至于為什么會出現(xiàn)r.leased+r.available>maxPerRoute的情況其實也很好理解，雖然在整個狀態(tài)流轉(zhuǎn)過程都加了鎖，但是狀態(tài)的流轉(zhuǎn)并不是原子操作，存在一些異常的場景都會導(dǎo)致狀態(tài)短時間不正確）；所以我們可以得出結(jié)論，maxPerRoute只是一個理論上的最大數(shù)值，其實真實產(chǎn)生的連接數(shù)在短時間內(nèi)是可能大于這個值的；
3. 在真實的連接數(shù)（r .leased+ r .available）小于maxPerRoute且maxTotal>leased的情況下：如果free>0，則重新創(chuàng)建一個連接；如果free=0，則把available容器里的最早創(chuàng)建的一個連接關(guān)閉掉，然后再重新創(chuàng)建一個連接；看起來有點繞，其實就是優(yōu)先使用free容器里的連接，獲取不到再釋放available容器里的連接；
4. 如果經(jīng)過上述過程仍然沒有獲取到可用連接，那就只能等待一個connectionRequestTimout時間，或者有其他線程的信號通知來結(jié)束整個獲取連接的過程。

3.6 連接的釋放

1. 如果是長連接（reusable），則把該連接從leased容器中刪除，然后添加到available容器的頭部，設(shè)置有效期為expiry；
2. 如果是短連接（non-reusable），則直接關(guān)閉該連接，并且從released容器中刪除，此時的連接被釋放，處于free容器中；
3. 最后，喚醒“連接的產(chǎn)生與管理“第四部中的等待線程。

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

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

那問題自然就只能出現(xiàn)在一些異常場景，導(dǎo)致了長連接沒有被及時關(guān)閉，結(jié)合最初的分析，是服務(wù)端主動斷開了連接，那大概率出現(xiàn)在一些超時導(dǎo)致連接斷開的異常場景，我們再回到

org.apache.http.impl.execchain.MainClientExec這個類，發(fā)現(xiàn)這樣幾行代碼：

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

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

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

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

四、總結(jié)

1. 連接池的主要功能有兩個：連接的管理和連接的復(fù)用，在使用連接池的時候一定要注意只需關(guān)閉當前數(shù)據(jù)流，而不要每次都關(guān)閉連接，除非你的目標訪問地址是完全隨機的；
2. maxTotal和maxPerRoute的設(shè)置一定要謹慎，合理的分配參數(shù)可以做到業(yè)務(wù)隔離，但如果無法準確做出評估，可以暫時設(shè)置成一樣，或者用兩個獨立的httpclient實例；
3. 一定記得要設(shè)置長連接的有效期，用PoolingHttpClientConnectionManager(60, TimeUnit.SECONDS)構(gòu)造函數(shù)，尤其是調(diào)用量較大的情況，防止發(fā)生不可預(yù)知的問題；
4. 可以通過設(shè)置evictIdleConnections(5, TimeUnit.SECONDS)定時清理空閑連接，尤其是http接口響應(yīng)時間短，并發(fā)量大的情況下，及時清理空閑連接，避免從連接池獲取連接的時候發(fā)現(xiàn)連接過期再去關(guān)閉連接，能在一定程度上提高接口性能。

五、寫在最后

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

1. 沒有提供監(jiān)控連接狀態(tài)的入口，也沒有提供能外部介入動態(tài)影響連接生命周期的擴展點，一旦線上出現(xiàn)問題可能就是致命的；
2. 此外，其獲取連接的方式是采用同步鎖的方式，在并發(fā)較高的情況下存在一定的性能瓶頸，而且其對長連接的管理方式存在問題，稍不注意就會導(dǎo)致建立大量異常長連接而無法及時釋放，造成系統(tǒng)性災(zāi)難。