HttpClient 與 Close_Wait
服務器A需要通過HttpClient去連接另一個系統B提供的服務，運行一段時間后拋出以下異常：java.net.SocketException: Connection reset by peer: socket write error close_wait
在服務器B上運行netstat命令，發現大量連接處于CLOSE_WAIT 狀態。
問題分析：
簡單來說CLOSE_WAIT數目過大是由于被動關閉連接處理不當導致的。
我說一個場景，服務器A會去請求服務器B上面的apache獲取文件資源，正常情況下，如果請求成功，那么在抓取完資源后服務器A會主動發出關閉連接的請求，這個時候就是主動關閉連接，連接狀態我們可以看到是TIME_WAIT。如果一旦發生異常呢?假設請求的資源服務器B上并不存在，那么這個時候就會由服務器B發出關閉連接的請求，服務器A就是被動的關閉了連接，如果服務器A被動關閉連接之后自己并沒有釋放連接，那就會造成CLOSE_WAIT的狀態了。
所以很明顯，問題還是處在程序里頭。
原始代碼塊：
- try
- {
- client = HttpConnectionManager.getHttpClient();
- HttpGet get = new HttpGet();
- get.setURI(new URI(urlPath));
- HttpResponse response = client.execute(get);
- if (response.getStatusLine ().getStatusCode () != 200) {
- return null;
- }
- HttpEntity entity =response.getEntity();
- if( entity != null ){
- in = entity.getContent();
- .....
- }
- return sb.toString ();
- }
- catch (Exception e)
- {
- e.printStackTrace ();
- return null;
- }
- finally
- {
- if (isr != null){
- try
- {
- isr.close ();
- }
- catch (IOException e)
- {
- e.printStackTrace ();
- }
- }
- if (in != null){
- try
- {
- <span style="color:#ff0000;">in.close ();</span>
- }
- catch (IOException e)
- {
- e.printStackTrace ();
- }
- }
- }
HttpClient使用我們常用的InputStream.close()來確認連接關閉，分析上面的代碼，一旦出現非200的連接，這個連接將永遠僵死在連接池里頭，因為inputStream得不到初始化，永遠不會調用close()方法了。
通過代碼稍微修改，更嚴謹的處理異常情況就可以解決問題了：
- public static String readNet (String urlPath)
- {
- StringBuffer sb = new StringBuffer ();
- HttpClient client = null;
- InputStream in = null;
- InputStreamReader isr = null;
- HttpGet get = new HttpGet();
- try
- {
- client = HttpConnectionManager.getHttpClient();
- get.setURI(new URI(urlPath));
- HttpResponse response = client.execute(get);
- if (response.getStatusLine ().getStatusCode () != 200) {
- get.abort();
- return null;
- }
- HttpEntity entity =response.getEntity();
- if( entity != null ){
- in = entity.getContent();
- ......
- }
- return sb.toString ();
- }
- catch (Exception e)
- {
- get.abort();
- e.printStackTrace ();
- return null;
- }
- finally
- {
- if (isr != null){
- try
- {
- isr.close ();
- }
- catch (IOException e)
- {
- e.printStackTrace ();
- }
- }
- if (in != null){
- try
- {
- in.close ();
- }
- catch (IOException e)
- {
- e.printStackTrace ();
- }
- }
- }
- }
顯示調用HttpGet的abort，這樣就會直接中止這次連接，我們在遇到異常的時候應該顯示調用，因為誰能保證異常是在InputStream in賦值之后才拋出的呢。
more:
首先我們知道，如果我們的服務器程序處于CLOSE_WAIT狀態的話，說明套接字是被動關閉的!
因為如果是CLIENT端主動斷掉當前連接的話，那么雙方關閉這個TCP連接共需要四個packet：
Client –-> FIN –-> Server Client <–- ACK <–- Server 這時候Client端處于FIN_WAIT_2狀態；而Server 程序處于CLOSE_WAIT狀態。 Client <–- FIN <–- Server 這時Server 發送FIN給Client，Server 就置為LAST_ACK狀態。 Client –-> ACK –-> Server Client回應了ACK，那么Server 的套接字才會真正置為CLOSED狀態。
Server 程序處于CLOSE_WAIT狀態，而不是LAST_ACK狀態，說明還沒有發FIN給Client，那么可能是在關閉連接之前還有許多數據要發送或者其他事要做，導致沒有發這個FIN packet。
通常來說，一個CLOSE_WAIT會維持至少2個小時的時間(這個時間外網服務器通常會做調整，要不然太危險了)。如果有個流氓特地寫了個程序，給你造成一堆的CLOSE_WAIT，消耗
你的資源，那么通常是等不到釋放那一刻，系統就已經解決崩潰了。
只能通過修改一下TCP/IP的參數，來縮短這個時間：修改tcp_keepalive_*系列參數有助于解決這個問題。
但是實際上，還是主要是因為我們的程序代碼有問題，
more:
最近做httpclient做轉發服務，發現服務器上總是有很多close_wait狀態的連接，而且這些連接都不會關閉，最后導致服務器沒法建立新的網絡連接，從而停止響應。
后來在網上搜索了一下，發現解決的方法也很簡單，如果想重用連接，那就使用連接管理器，從連接管理器里獲取連接，然后定時的用連接管理器來釋放空閑連接。httpclient自帶了SimpleHttpConnectionManager，提供了
Java代碼
- closeIdleConnections(long idleTimeout)
這樣的方法。
如果不需要重用鏈接，則直接在httpmethod創建時，設置一個http頭信息就可以了
Java代碼
- httpmethod.setRequestHeader("Connection", "close");
這樣就不會有惱人的close_wait了。
