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後），若是再繼續寫數據則拋出該異常。前兩個異常的解決方法是首先確保程序退出前關閉全部的網絡鏈接，其次是要檢測對方的關閉鏈接操做，發現對 方關閉鏈接後本身也要關閉該鏈接。

　　 二．編寫網絡程序時須要注意的問題:

　　一、是要正確區分長、短鏈接。所謂的長鏈接是指一經創建就永久保持。短鏈接的狀況是，準備數據—>創建鏈接—>發送數據—>關閉鏈接。不少的程序員寫了多年的網絡程序，竟然不知道什麼是長鏈接，什麼是短鏈接。

　 　二、是對長鏈接的維護。所謂維護包括兩個方面，首先是檢測對方的主動斷連（即調用 Socket的close方法），其次是檢測對方的宕機、異常退出及網絡不通。這是一個健壯的通訊程序必須具有的。檢測對方的主動斷連很簡單，主要一方主 動斷連，另外一方若是在進行讀操做，則此時的返回值只-1，一旦檢測到對方斷連，則應該主動關閉本端的鏈接（調用Socket的close方法）。而檢測對 方的宕機、異常退出及網絡不通，經常使用方法是用「心跳」，也就是雙方週期性的發送數據給對方，同時也從對方接收「心跳」，若是連續幾個週期都沒有收到對方心 跳，則能夠判斷對方宕機、異常退出或者網絡不通，此時也須要主動關閉本端鏈接，若是是客戶端可在延遲必定時間後從新發起鏈接。雖然Socket有一個 keep alive選項來維護鏈接，若是用該選項，通常須要兩個小時才能發現對方的宕機、異常退出及網絡不通。

　　三、是處理效 率問題。不論是客戶端仍是服務器，若是是長鏈接一個程序至少須要兩個線程，一個用於接收數據，一個用於發送心跳，寫數據不須要專門的線程，固然另外還須要 一類線程（俗稱Worker線程）用於進行消息的處理，也就是說接收線程僅僅負責接收數據，而後再分發給Worker進行數據的處理。若是是短鏈接，則不 須要發送心跳的線程，若是是服務器還須要一個專門的線程負責進行鏈接請求的監聽。這些是一個通訊程序的總體要求，具體到你的程序中，就看你如何對程序進行 優化了。