服務(wù)器A需要通過HttpClient去連接另一個系統(tǒng)B提供的服務(wù)，運行一段時間后拋出以下異常：java.net.SocketException: Connection reset by peer: socket write error close_wait

在服務(wù)器B上運行netstat命令，發(fā)現(xiàn)大量連接處于CLOSE_WAIT 狀態(tài)。

問題分析：

簡單來說CLOSE_WAIT數(shù)目過大是由于被動關(guān)閉連接處理不當(dāng)導(dǎo)致的。

我說一個場景，服務(wù)器A會去請求服務(wù)器B上面的apache獲取文件資源，正常情況下，如果請求成功，那么在抓取完資源后服務(wù)器A會主動發(fā)出關(guān)閉連接的請求，這個時候就是主動關(guān)閉連接，連接狀態(tài)我們可以看到是TIME_WAIT。如果一旦發(fā)生異常呢?假設(shè)請求的資源服務(wù)器B上并不存在，那么這個時候就會由服務(wù)器B發(fā)出關(guān)閉連接的請求，服務(wù)器A就是被動的關(guān)閉了連接，如果服務(wù)器A被動關(guān)閉連接之后自己并沒有釋放連接，那就會造成CLOSE_WAIT的狀態(tài)了。

所以很明顯，問題還是處在程序里頭。

原始代碼塊：

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()來確認(rèn)連接關(guān)閉，分析上面的代碼，一旦出現(xiàn)非200的連接，這個連接將永遠(yuǎn)僵死在連接池里頭，因為inputStream得不到初始化，永遠(yuǎn)不會調(diào)用close()方法了。

通過代碼稍微修改，更嚴(yán)謹(jǐn)?shù)奶幚懋惓Ｇ闆r就可以解決問題了：

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

顯示調(diào)用HttpGet的abort，這樣就會直接中止這次連接，我們在遇到異常的時候應(yīng)該顯示調(diào)用，因為誰能保證異常是在InputStream in賦值之后才拋出的呢。

more:

首先我們知道，如果我們的服務(wù)器程序處于CLOSE_WAIT狀態(tài)的話，說明套接字是被動關(guān)閉的!

因為如果是CLIENT端主動斷掉當(dāng)前連接的話，那么雙方關(guān)閉這個TCP連接共需要四個packet：

Client –-> FIN  –-> Server
Client <–- ACK  <–- Server
這時候Client端處于FIN_WAIT_2狀態(tài)；而Server 程序處于CLOSE_WAIT狀態(tài)。
Client <–- FIN  <–- Server
這時Server 發(fā)送FIN給Client，Server 就置為LAST_ACK狀態(tài)。
Client –-> ACK  –-> Server
Client回應(yīng)了ACK，那么Server 的套接字才會真正置為CLOSED狀態(tài)。

Server 程序處于CLOSE_WAIT狀態(tài)，而不是LAST_ACK狀態(tài)，說明還沒有發(fā)FIN給Client，那么可能是在關(guān)閉連接之前還有許多數(shù)據(jù)要發(fā)送或者其他事要做，導(dǎo)致沒有發(fā)這個FIN packet。

通常來說，一個CLOSE_WAIT會維持至少2個小時的時間(這個時間外網(wǎng)服務(wù)器通常會做調(diào)整，要不然太危險了)。如果有個流氓特地寫了個程序，給你造成一堆的CLOSE_WAIT，消耗

你的資源，那么通常是等不到釋放那一刻，系統(tǒng)就已經(jīng)解決崩潰了。

只能通過修改一下TCP/IP的參數(shù)，來縮短這個時間：修改tcp_keepalive_*系列參數(shù)有助于解決這個問題。

但是實際上，還是主要是因為我們的程序代碼有問題，

more:

最近做httpclient做轉(zhuǎn)發(fā)服務(wù)，發(fā)現(xiàn)服務(wù)器上總是有很多close_wait狀態(tài)的連接，而且這些連接都不會關(guān)閉，最后導(dǎo)致服務(wù)器沒法建立新的網(wǎng)絡(luò)連接，從而停止響應(yīng)。

后來在網(wǎng)上搜索了一下，發(fā)現(xiàn)解決的方法也很簡單，如果想重用連接，那就使用連接管理器，從連接管理器里獲取連接，然后定時的用連接管理器來釋放空閑連接。httpclient自帶了SimpleHttpConnectionManager，提供了

Java代碼 

closeIdleConnections(long idleTimeout)  

這樣的方法。

如果不需要重用鏈接，則直接在httpmethod創(chuàng)建時，設(shè)置一個http頭信息就可以了

Java代碼

httpmethod.setRequestHeader("Connection", "close");   

這樣就不會有惱人的close_wait了。