在java網絡編程Socket通信中 通常會遇到以下異常情況
第 個異常是 BindException:Address already in use: JVM_Bind
該異常發生在服務器端進行new ServerSocket(port)（port是壹個 的整型值）操作時 異常的原因是以為與port壹樣的壹個端口已經被啟動 並進行監聽 此時用netstat an命令 可以看到壹個Listending狀態的端口 只需要找壹個沒有被占用的端口就能解決該問題了
第 個異常是 ConnectException: Connection refused: connect
該異常發生在客戶端進行 new Socket(ip port)操作時 該異常發生的原因是或者具有ip地址的機器不能找到（也就是說從當前機器不存在到指定ip路由） 或者是該ip存在 但找不到指定的端口進行監聽 出現該問題 首先檢查客戶端的ip和port是否寫錯 如果正確則從客戶端ping壹下服務器看是否能ping通 如果能ping通（服務器端把ping禁掉則需要另外的辦法） 則看在服務器端的監聽指定端口的程序是否啟動 這個肯定能解決這個問題
第 個異常是 SocketException: Socket is closed
該異常在客戶端和服務器均可能發生 異常的原因是本端主動關閉了連接後（調用了Socket的close方法）再對網絡連接進行讀寫操作
第 個異常是 SocketException: （Connection reset或者Connect reset by peer:Socket write error）
該異常在客戶端和服務器端均有可能發生 引起該異常的原因有兩個 第壹個就是如果壹端的Socket被關閉（或主動關閉或者因為異常退出而引起的關閉） 另壹端仍發送數據 發送的第壹個數據包引發該異常(Connect reset by peer) 另壹個是壹端退出 但退出時並未關閉該連接 另壹端如果在從連接中讀數據則拋出該異常（Connection reset） 簡單的說就是由連接斷開後的讀和寫操作引起的
第 個異常是 SocketException: Broken pipe
該異常在客戶端和服務器均有可能發生 在第 個異常的第壹種情況中（也就是拋出 SocketExcepton:Connect reset by peer:Socket write error後） 如果再繼續寫數據則拋出該異常 前兩個異常的解決方法是首先確保程序退出前關閉所有的網絡連接 其次是要檢測對方的關閉連接操作 發現對方關閉連接後自己也要關閉該連接
二．編寫網絡程序時需要註意的問題:
是要正確區分長 短連接 所謂的長連接是指壹經建立就永久保持 短連接的情況是 準備數據—>建立連接—>發送數據—>關閉連接 很多的程序員寫了多年的網絡程序 居然不知道什麽是長連接 什麽是短連接
是對長連接的維護 所謂維護包括兩個方面 首先是檢測對方的主動斷連（即調用 Socket的close方法） 其次是檢測對方的宕機 異常退出及網絡不通 這是壹個健壯的通信程序必須具備的 檢測對方的主動斷連很簡單 主要壹方主動斷連 另壹方如果在進行讀操作 則此時的返回值只 壹旦檢測到對方斷連 則應該主動關閉本端的連接（調用Socket的close方法） 而檢測對方的宕機 異常退出及網絡不通 常用方法是用 心跳 也就是雙方周期性的發送數據給對方 同時也從對方接收 心跳 如果連續幾個周期都沒有收到對方心跳 則可以判斷對方宕機 異常退出或者網絡不通 此時也需要主動關閉本端連接 如果是客戶端可在延遲壹定時間後重新發起連接 雖然Socket有壹個keep alive選項來維護連接 如果用該選項 壹般需要兩個小時才能發現對方的宕機 異常退出及網絡不通
lishixinzhi/Article/program/Java/hx/201311/26630