HttpClient連接池拋出大量ConnectionPoolTimeoutException: Timeout waiting for connection異常排查
今天解決了一個HttpClient的異常，汗啊，一個HttpClient使用稍有不慎都會是毀滅級別的啊。
這里有之前因為route配置不當導致服務器異常的一個處理：http://blog.csdn.net/shootyou/article/details/6415248
里面的HttpConnectionManager實現就是我在這里使用的實現。
簡單來說CLOSE_WAIT數目過大是由於被動關閉連接處理不當導致的。
我說一個場景，服務器A會去請求服務器B上面的apache獲取文件資源，正常情況下，如果請求成功，那么在抓取完資源后服務器A會主動發出關閉連接的請求，這個時候就是主動關閉連接，連接狀態我們可以看到是TIME_WAIT。如果一旦發生異常呢？假設請求的資源服務器B上並不存在，那么這個時候就會由服務器B發出關閉連接的請求，服務器A就是被動的關閉了連接，如果服務器A被動關閉連接之后自己並沒有釋放連接，那就會造成CLOSE_WAIT的狀態了。
一、“多半是程序的原因”？這個還是交給程序猿吧
二、linux 下 CLOSE_WAIT過多的解決方法
情景描述：系統產生大量“Too many open files”
原因分析：在服務器與客戶端通信過程中，因服務器發生了socket未關導致的closed_wait發生，致使監聽port打開的句柄數到了1024個，且均處於close_wait的狀態，最終造成配置的port被占滿出現“Too many open files”，無法再進行通信。
close_wait狀態出現的原因是被動關閉方未關閉socket造成
解決辦法：有兩種措施可行
一、解決：
原因是因為調用ServerSocket類的accept()方法和Socket輸入流的read()方法時會引起線程阻塞，所以應該用setSoTimeout()方法設置超時（缺省的設置是0，即超時永遠不會發生）；超時的判斷是累計式的，一次設置后，每次調用引起的阻塞時間都從該值中扣除，直至另一次超時設置或有超時異常拋出。
比如，某種服務需要三次調用read()，超時設置為1分鍾，那么如果某次服務三次read()調用的總時間超過1分鍾就會有異常拋出，如果要在同一個Socket上反復進行這種服務，就要在每次服務之前設置一次超時。
二、規避：
調整系統參數，包括句柄相關參數和TCP/IP的參數；
注意：
/proc/sys/fs/file-max 是整個系統可以打開的文件數的限制，由sysctl.conf控制；
ulimit修改的是當前shell和它的子進程可以打開的文件數的限制，由limits.conf控制；
lsof是列出系統所占用的資源,但是這些資源不一定會占用打開文件號的；比如：共享內存,信號量,消息隊列,內存映射等,雖然占用了這些資源,但不占用打開文件號；
因此，需要調整的是當前用戶的子進程打開的文件數的限制，即limits.conf文件的配置；
如果cat /proc/sys/fs/file-max值為65536或甚至更大，不需要修改該值；
若ulimit -a ；其open files參數的值小於4096（默認是1024), 則采用如下方法修改open files參數值為8192；方法如下：
1.使用root登陸，修改文件/etc/security/limits.conf
vim /etc/security/limits.conf添加
xxx - nofile 8192
xxx 是一個用戶，如果是想所有用戶生效的話換成 * ，設置的數值與硬件配置有關，別設置太大了。
#<domain> <type> <item> <value> * soft nofile 8192 * hard nofile 8192#所有的用戶每個進程可以使用8192個文件描述符。
2.使這些限制生效
確定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行：
session required pam_limits.so
然后用戶重新登陸一下即可生效。
3. 在bash下可以使用ulimit -a 參看是否已經修改：
一、 修改方法：（暫時生效,重新啟動服務器后,會還原成默認值）
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_keepalive_intvl=2注意：Linux的內核參數調整的是否合理要注意觀察，看業務高峰時候效果如何。
二、 若做如上修改后，可起作用；則做如下修改以便永久生效。
vi /etc/sysctl.conf
若配置文件中不存在如下信息，則添加：
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15編輯完 /etc/sysctl.conf,要重啟network 才會生效
/etc/rc.d/init.d/network restart
然后，執行sysctl命令使修改生效，基本上就算完成了。
修改原因：
當客戶端因為某種原因先於服務端發出了FIN信號，就會導致服務端被動關閉，若服務端不主動關閉socket發FIN給Client，此時服務端Socket會處於CLOSE_WAIT狀態（而不是LAST_ACK狀態）。通常來說，一個CLOSE_WAIT會維持至少2個小時的時間（系統默認超時時間的是7200秒，也就是2小時）。如果服務端程序因某個原因導致系統造成一堆CLOSE_WAIT消耗資源，那么通常是等不到釋放那一刻，系統就已崩潰。因此，解決這個問題的方法還可以通過修改TCP/IP的參數來縮短這個時間，於是修改tcp_keepalive_*系列參數：
tcp_keepalive_time：
/proc/sys/net/ipv4/tcp_keepalive_time 點擊打開鏈接
INTEGER，默認值是7200(2小時)
當keepalive打開的情況下，TCP發送keepalive消息的頻率。建議修改值為1800秒。
tcp_keepalive_probes：INTEGER
/proc/sys/net/ipv4/tcp_keepalive_probes
INTEGER，默認值是9
TCP發送keepalive探測以確定該連接已經斷開的次數。(注意:保持連接僅在SO_KEEPALIVE套接字選項被打開是才發送.次數默認不需要修改,當然根據情形也可以適當地縮短此值.設置為5比較合適)
tcp_keepalive_intvl：INTEGER
/proc/sys/net/ipv4/tcp_keepalive_intvl
INTEGER，默認值為75
當探測沒有確認時，重新發送探測的頻度。探測消息發送的頻率（在認定連接失效之前，發送多少個TCP的keepalive探測包）。乘以tcp_keepalive_probes就得到對於從開始探測以來沒有響應的連接殺除的時間。默認值為75秒，也就是沒有活動的連接將在大約11分鍾以后將被丟棄。(對於普通應用來說,這個值有一些偏大,可以根據需要改小.特別是web類服務器需要改小該值,15是個比較合適的值)
1. 系統不再出現“Too many open files”報錯現象。
2. 處於TIME_WAIT狀態的sockets不會激長。
在 Linux 上可用以下語句看了一下服務器的TCP狀態(連接狀態數量統計)：
netstat -n| awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
服務器TIME_WAIT和CLOSE_WAIT詳解和解決辦法
在服務器的日常維護過程中，會經常用到下面的命令：
- netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
它會顯示例如下面的信息：
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1
常用的三個狀態是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。
具體每種狀態什么意思，其實無需多說，看看下面這種圖就明白了，注意這里提到的服務器應該是業務請求接受處理的一方：
這么多狀態不用都記住，只要了解到我上面提到的最常見的三種狀態的意義就可以了。一般不到萬不得已的情況也不會去查看網絡狀態，如果服務器出了異常，百分之八九十都是下面兩種情況：
1.服務器保持了大量TIME_WAIT狀態
2.服務器保持了大量CLOSE_WAIT狀態
因為linux分配給一個用戶的文件句柄是有限的（可以參考：http://blog.csdn.net/shootyou/article/details/6579139），而TIME_WAIT和CLOSE_WAIT兩種狀態如果一直被保持，那么意味着對應數目的通道就一直被占着，而且是“占着茅坑不使勁”，一旦達到句柄數上限，新的請求就無法被處理了，接着就是大量Too Many Open Files異常，tomcat崩潰。。。
下 面來討論下這兩種情況的處理方法，網上有很多資料把這兩種情況的處理方法混為一談，以為優化系統內核參數就可以解決問題，其實是不恰當的，優化系統內核參 數解決TIME_WAIT可能很容易，但是應對CLOSE_WAIT的情況還是需要從程序本身出發。現在來分別說說這兩種情況的處理方法：
1.服務器保持了大量TIME_WAIT狀態
這種情況比較常見，一些爬蟲服務器或者WEB服務器（如果網管在安裝的時候沒有做內核參數優化的話）上經常會遇到這個問題，這個問題是怎么產生的呢？
從 上面的示意圖可以看得出來，TIME_WAIT是主動關閉連接的一方保持的狀態，對於爬蟲服務器來說他本身就是“客戶端”，在完成一個爬取任務之后，他就 會發起主動關閉連接，從而進入TIME_WAIT的狀態，然后在保持這個狀態2MSL（max segment lifetime）時間之后，徹底關閉回收資源。為什么要這么做？明明就已經主動關閉連接了為啥還要保持資源一段時間呢？這個是TCP/IP的設計者規定 的，主要出於以下兩個方面的考慮：
1.防止上一次連接中的包，迷路后重新出現，影響新連接（經過2MSL，上一次連接中所有的重復包都會消失）
2. 可靠的關閉TCP連接。在主動關閉方發送的最后一個 ack(fin) ，有可能丟失，這時被動方會重新發fin, 如果這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。另外這么設計TIME_WAIT 會定時的回收資源，並不會占用很大資源的，除非短時間內接受大量請求或者受到攻擊。
關於MSL引用下面一段話：
- MSL 為 一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由 於 RFC 793 TCP 傳輸協定是在 1981 年定義的，當時的網路速度不像現在的網際網路那樣發達，你可以想像你從瀏覽器輸入網址等到第一 個 byte 出現要等 4 分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低，好 讓 連線埠 (Ports) 能更快空出來給其他連線使用。
再引用網絡資源的一段話：
- 值 得一說的是，對於基於TCP的HTTP協議，關閉TCP連接的是Server端，這樣，Server端會進入TIME_WAIT狀態，可 想而知，對於訪 問量大的Web Server，會存在大量的TIME_WAIT狀態，假如server一秒鍾接收1000個請求，那么就會積壓 240*1000=240，000個 TIME_WAIT的記錄，維護這些狀態給Server帶來負擔。當然現代操作系統都會用快速的查找算法來管理這些 TIME_WAIT，所以對於新的 TCP連接請求，判斷是否hit中一個TIME_WAIT不會太費時間，但是有這么多狀態要維護總是不好。
- HTTP協議1.1版規定default行為是Keep-Alive，也就是會重用TCP連接傳輸多個 request/response，一個主要原因就是發現了這個問題。
也就是說HTTP的交互跟上面畫的那個圖是不一樣的，關閉連接的不是客戶端，而是服務器，所以web服務器也是會出現大量的TIME_WAIT的情況的。
- #對於一個新建連接，內核要發送多少個 SYN 連接請求才決定放棄,不應該大於255，默認值是5，對應於180秒左右時間
- net.ipv4.tcp_syn_retries=2
- #net.ipv4.tcp_synack_retries=2
- #表示當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改為300秒
- net.ipv4.tcp_keepalive_time=1200
- net.ipv4.tcp_orphan_retries=3
- #表示如果套接字由本端要求關閉，這個參數決定了它保持在FIN-WAIT-2狀態的時間
- net.ipv4.tcp_fin_timeout=30
- #表示SYN隊列的長度，默認為1024，加大隊列長度為8192，可以容納更多等待連接的網絡連接數。
- net.ipv4.tcp_max_syn_backlog = 4096
- #表示開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉
- net.ipv4.tcp_syncookies = 1
- #表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉
- net.ipv4.tcp_tw_reuse = 1
- #表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉
- net.ipv4.tcp_tw_recycle = 1
- ##減少超時前的探測次數
- net.ipv4.tcp_keepalive_probes=5
- ##優化網絡設備接收隊列
- net.core.netdev_max_backlog=3000
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*