按照NIO的规范来说，对于非阻塞Channel，如果当前write方法无法发送任何字节，则应该返回0，而不是抛出异常。

以前我就发现了它的一个Bug ： 在Java 1.4的虚拟机上，SocketChannel的write(ByteBuffer[])的JNI操作实现中没有检测某个返回值，抛出了 java.io.IOException: A non-blocking socket operation could not be completed immediately异常。而这种情况下本应该返回0的。好在这个Bug不影响大局，一般只要绕过对该方法的调用即可，况且这个Bug已经在Java 5.0中得到了解决。

不过今天又发现了它的一个Bug：SocketChannel的write(ByteBuffer)的JNI操作，在Window的实现上没有检测 WSAENOBUFS的返回值，抛出了java.io.IOException: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full异常。而这种情况下也本应该返回0的。

应该很少会有应用会触发这个异常，我之所以发现了这个异常也是运气：） 在Cindy简单的HttpServer示例中，图个方便简单的使用了内存映射文件，而且不管文件大小都是全部映射（我是示例Cindy的用法，千万不要 在生产系统中这么做）。晚上测试一个200多M文件的下载，我的内存肯定是足够的，所以内存映射没有出现任何问题，但是一次性通过write方法发送 200多M的Direct ByteBuffer，呵呵，这个现象就能重现出来了：）

实际应用中应该不会有人象我这么玩的，呵呵，所以这个Bug影响倒也不大。对于应用来说，一方面是不要一次性发送这么大的数据，另一方面是增大 Socket的发送缓冲区大小。对于Cindy而言，要对应用屏蔽这个Bug，即使应用发送这么大的数据也不要触发这个异常，倒是有一个简单的方法：把传递给write方法的ByteBuffer控制在一定的字节数内。

即使应用要Cindy发送一个200M的ByteBuffer，也可以控制成每次调用write方法时，只传给它一个1M大的ByteBuffer，分200次发送即可。这样就可以简单的对应用屏蔽这个Bug了。