Java Socket常見異常處理

在java網絡程式設計socket通信中，通常會遇到以下異常情況：

　　第1個異常是 java.net.bindexception:address already in use: jvm_bind。

　　該異常發生在伺服器端進行new serversocket(port)（port是一個0，65536的整型值）操作時。異常的原因是以為與port一樣的一個端口已經被啟動，并進行監聽。此時用netstat -an指令，可以看到一個listending狀态的端口。隻需要找一個沒有被占用的端口就能解決該問題了。

　　第2個異常是java.net.connectexception: connection refused: connect。

　　該異常發生在用戶端進行 new socket(ip, port)操作時，該異常發生的原因是或者具有ip位址的機器不能找到（也就是說從目前機器不存在到指定ip路由），或者是該ip存在，但找不到指定的端口進行監聽。出現該問題，首先檢查用戶端的ip和port是否寫錯，如果正确則從用戶端ping一下伺服器看是否能ping通，如果能ping通（伺服器端把ping禁掉則需要另外的辦法），則看在伺服器端的監聽指定端口的程式是否啟動，這個肯定能解決這個問題。

　　第3個異常是java.net.socketexception: socket is closed。

　　該異常在用戶端和伺服器均可能發生。異常的原因是本端主動關閉了連接配接後（調用了socket的close方法）再對網絡連接配接進行讀寫操作。

　　第4個異常是java.net.socketexception: （connection reset或者connect reset by peer:socket write error）。

　　該異常在用戶端和伺服器端均有可能發生，引起該異常的原因有兩個，第一個就是如果一端的socket被關閉（或主動關閉或者因為異常退出而引起的關閉），另一端仍發送資料，發送的第一個資料包引發該異常(connect reset by peer)。另一個是一端退出，但退出時并未關閉該連接配接，另一端如果在從連接配接中讀資料則抛出該異常（connection reset）。簡單的說就是由連接配接斷開後的讀和寫操作引起的。

　　第5個異常是java.net.socketexception: broken pipe。

　　該異常在用戶端和伺服器均有可能發生。在第4個異常的第一種情況中（也就是抛出 socketexcepton:connect reset by peer:socket write error後），如果再繼續寫資料則抛出該異常。前兩個異常的解決方法是首先確定程式退出前關閉所有的網絡連接配接，其次是要檢測對方的關閉連接配接操作，發現對方關閉連接配接後自己也要關閉該連接配接。

　　二．編寫網絡程式時需要注意的問題:

　　1、是要正确區分長、短連接配接。所謂的長連接配接是指一經建立就永久保持。短連接配接的情況是，準備資料—>建立連接配接—>發送資料—>關閉連接配接。很多的程式員寫了多年的網絡程式，居然不知道什麼是長連接配接，什麼是短連接配接。

　　2、是對長連接配接的維護。所謂維護包括兩個方面，首先是檢測對方的主動斷連（即調用 socket的close方法），其次是檢測對方的當機、異常退出及網絡不通。這是一個健壯的通信程式必須具備的。檢測對方的主動斷連很簡單，主要一方主動斷連，另一方如果在進行讀操作，則此時的傳回值隻-1，一旦檢測到對方斷連，則應該主動關閉本端的連接配接（調用socket的close方法）。而檢測對方的當機、異常退出及網絡不通，常用方法是用“心跳”，也就是雙方周期性的發送資料給對方，同時也從對方接收“心跳”，如果連續幾個周期都沒有收到對方心跳，則可以判斷對方當機、異常退出或者網絡不通，此時也需要主動關閉本端連接配接，如果是用戶端可在延遲一定時間後重新發起連接配接。雖然socket有一個keep alive選項來維護連接配接，如果用該選項，一般需要兩個小時才能發現對方的當機、異常退出及網絡不通。

　　3、是處理效率問題。不管是用戶端還是伺服器，如果是長連接配接一個程式至少需要兩個線程，一個用于接收資料，一個用于發送心跳，寫資料不需要專門的線程，當然另外還需要一類線程（俗稱worker線程）用于進行消息的處理，也就是說接收線程僅僅負責接收資料，然後再分發給worker進行資料的處理。如果是短連接配接，則不需要發送心跳的線程，如果是伺服器還需要一個專門的線程負責進行連接配接請求的監聽。這些是一個通信程式的整體要求，具體到你的程式中，就看你如何對程式進行優化了。