一天里會拋出幾個這樣的錯誤，但發現服務還在正常的運行。
java.io.IOException: 指定的網絡名不再可用。
at sun.nio.ch.Iocp.translateErrorToIOException(Unknown Source)
at sun.nio.ch.Iocp.access$700(Unknown Source)
at sun.nio.ch.Iocp$EventHandlerTask.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
在本地用ab進行並發測試的時候，比如： ab -n 2000 -c 200 -k http://xxx/....
當還沒有運行完的時候，按Ctrl + C，服務端程序也會拋出這個異常。
說明，有可能是在發起TCP(這個可能性大一些)或關閉TCP的時候，握手沒有完成。
由於在windows上，底層用Iocp實現，通過網上搜索：iocp 指定的網絡名不再可用，知道了這個錯誤的iocp錯誤碼：64，然后搜索：iocp 錯誤 64，找到幾篇比較有價值的文章，下面是摘抄的一部分重點：
來源：http://topic.csdn.net/u/20080606/11/cdaaccab-e4b0-4e67-9194-8107a019a1e9.html
我們使用完成端口模式編寫了一個提供下載的服務器，然后編寫了一個測試程序模擬100個客戶端來從服務器下載文件，測試程序是通過開啟100個線程，以每個線程當作一個客戶端來下載文件的，但是測試過程中出現了以下問題：
經過在多台機器上的測試，只有少數機器出現以下問題，其中最顯著的機器網速是10mbps的。
在成功連接后，文件傳輸過程中，服務器工作者線程的GetQueuedCompletionStatus處出現了64錯誤（ERROR_NETNAME_DELETED），但是客戶端沒有退出也沒有任何錯誤輸出，把客戶端線程數減少到10個時就不會出現這個問題。
哪位朋友知道這種問題的原因，請幫忙分析一下吧，謝謝大家了！（如果是不能解決的問題，也得有合理的解釋，不然沒法和客戶解釋）
回復1：
ERROR_NETNAME_DELETED（64 #錯誤）在我的測試中是在 client 非正常關閉 TCP 通道時會出現，即關閉的 4 次握手沒有正常完成時出現。如果很好的（graceful）完成關閉，比如c/s雙方shutdown等, GetQueuedCompletionStatus會成功,會pNumberOfBytes = 0
但是很多時候 TCP 通道會非正常關閉，這很正常，所以出現 ERROR_NETNAME_DELETED 也沒有什么可怕的。
回復2：
這個錯誤，我也碰到過，分析得到的結論主要還是因為IOCP滿負載工作，特別是有眾多的未決IO的時候，可能某一個客戶端在長時間內得不到影響就會由內核因超時而斷掉。建議在這個時候，使用NetStat 查看一下相關的連接狀態。
回復3：
我再描述一下測試發現的問題的一點規律吧。
在網速100mbps的機子上基本不出現該問題，基本上總是網速為10mbps的機子出現這個問題。還有就是在10mbps的機子上測試發現，模擬100個至少有20個左右出現問題，隨着模擬數降低，出現問題的個數也會減少，減少到20個時，測試10次中只有一次出現了一個該問題，減少到10個時，在測試中沒出現過該問題。
還有就是請大家注意一下，服務器出現64錯誤時：
1.客戶端使用非阻塞型套接字時，客戶端有超時輸出
2.客戶端使用阻塞型套接字時，客戶端沒有相應的輸出
由此我認為服務器出現64錯誤時客戶端並沒有退出，而是阻塞住了。
回復4：
問題基本已經確定，應該是由於客戶端的處理速度太慢，緩沖區總是滿的，導致服務器認為對方結束了連接。
我是這樣確定問題的，現在貼出來希望能給大家一些幫助：
由於iocp的不可控，不方便跟蹤，於是服務器端我們采用普通模式，即接到一個連接就開一個線程來處理。然后跟蹤調試服務器端，而客戶端采用寫log的方式來跟蹤，最后確定出64錯誤的連接在服務器端是出現在文件傳輸過程中的send處，而服務器出64錯誤的時候，客戶端是阻塞在recv處的（我測試時使用的是阻塞型套接字）。
之后就采用降低服務器發送速度的方式（比如在send前Sleep一下）測試一下，經過多次驗證，發現只要服務器發送的速度在客戶端的可承受范圍內的時候（比如客戶端開50個線程的時候服務器Sleep(50)，開100個現成的時候就得多Sleep一會），就不會再出現這個問題。
2012-06-27