轉載地址http://blog.csdn.net/cao478208248/article/details/41648359
當socketChannel為阻塞方式時（默認就是阻塞方式）read函數，不會返回0，阻塞方式的socketChannel，若沒有數據可讀，或者緩沖區滿了，就會阻塞，直到滿足讀的條件，所以一般阻塞方式的read是比較簡單的，不過阻塞方式的socketChannel的問題也是顯而易見的。這里我結合基於NIO 寫ftp服務器調試過程中碰到的問題，總結一下非阻塞場景下的read碰到的問題。注意：這里的場景都是基於客戶端以阻塞socket的方式發送數據。
1、read什么時候返回-1
read返回-1說明客戶端的數據發送完畢，並且主動的close socket。所以在這種場景下，（服務器程序）你需要關閉socketChannel並且取消key，最好是退出當前函數。注意，這個時候服務端要是繼續使用該socketChannel進行讀操作的話，就會拋出“遠程主機強迫關閉一個現有的連接”的IO異常。
2、read什么時候返回0
其實read返回0有3種情況，一是某一時刻socketChannel中當前（注意是當前）沒有數據可以讀，這時會返回0，其次是bytebuffer的position等於limit了，即bytebuffer的remaining等於0，這個時候也會返回0，最后一種情況就是客戶端的數據發送完畢了（注意看后面的程序里有這樣子的代碼），這個時候客戶端想獲取服務端的反饋調用了recv函數，若服務端繼續read，這個時候就會返回0。
-------------------------------------------------------------------------------------------------
實際寫代碼過程中觀察發現，如果客戶端發送數據后不關閉channel，同時服務端收到數據后反倒再次發給客戶端，那么此時客戶端read方法永遠返回0.