NIO中SocketChannel read()返回0的原因

转载地址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.