服務器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了。