java.net.SocketException如何才能更好的使用呢？這個就需要我們先要了解有關這個語言的相關問題。希望大家有所幫助。那麽我們就來看看有關java.net.SocketException的相關知識。

第1個異常是 java.net.BindException:Address already in use: JVM_Bind。

該異常發生在服務器端進行new ServerSocket(port)（port是一個0，65536的整型值）操作時。異常的原因是以為與port一樣的一個端口已經被啟動，並進行監聽。此時用netstat –an命令，可以看到一個Listending狀態的端口。只需要找一個沒有被占用的端口就能解決這個問題。

第2個異常是java.net.SocketException: 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進行數據的處理。如果是短連接，則不需要發送心跳的線程，如果是服務器還需要一個專門的線程負責進行連接請求的監聽。這些是一個通信程序的整體要求，具體怎麽設計你的程序，就看你自己的設計水平了。