NIO的一坑一惑小记

前言

　　不知不觉，已那么长时间没有更新东西了，说来真是汗颜啊。（主要是最近在技术上豁然开朗的感觉越来越少了-_-|||）

　　最近一直在学习Linux相关的东西。又一次接触到了I/O复用模型（select/poll/epoll），由于好久没在用NIO写过代码了，今天就小试写个例子，以巩固下对I/O复用模型的理解。这不，遇到了一个坑，也产生了一点疑惑。^_^。

一坑

　　简单描述：Selector的select方法返回的key集合中有一个SelectionKey是可读的，但是调用与此SelectionKey关联的channel的read方法，总是返回读取长度是-1。既然返回-1,可以说明tcp链接已经断开。在下次调用select方法不应再返回这个SelectionKey，也不应该此SelectionKey是可读状态的。但事实并非如此：

public class NIOMain {
 
    public static void main(String[] args) throws Exception {
        Selector selector = Selector.open();
        ServerSocketChannel serverChannel = ServerSocketChannel.open();
        serverChannel.configureBlocking(false);
        serverChannel.socket().bind(new InetSocketAddress(9000), 10);
        serverChannel.register(selector, SelectionKey.OP_ACCEPT);
         
        doSelect(selector);
         
    }
     
    public static void doSelect(Selector selector)throws Exception{
        while (true) {
            int srt=selector.select();
            if(srt<=0){
                continue;
            }
            Set<SelectionKey> keys = selector.selectedKeys();
            Iterator<SelectionKey> iter = keys.iterator();
             
            while(iter.hasNext()){
                SelectionKey key = iter.next();
                if(key.isAcceptable()){
                    ServerSocketChannel  sChannel= (ServerSocketChannel) key.channel();
                    SocketChannel cChannel = sChannel.accept();
                    cChannel.configureBlocking(false);
                    cChannel.register(selector, SelectionKey.OP_READ);
                }else if(key.isReadable()){
                    SocketChannel cChannel = (SocketChannel) key.channel();
                    ByteBuffer bb = ByteBuffer.allocate(1024);
                    int len =cChannel.read(bb);
                    bb.flip();
                    if(bb.hasArray() && len>0){
                        System.out.println("from client "+":"+ new String(bb.array(),0,len));
                        int newInterestOps = key.interestOps();
                        newInterestOps |= SelectionKey.OP_WRITE;
                        key.interestOps(newInterestOps);
                    }else if(len==-1){
                        System.out.println("no data");//在这里不能忘记关闭channel
                    }
                     
                    bb.clear();
                }
                iter.remove();
            }
        }
    }
 
}

　　运行此代码，然后在浏览器里输入127.0.0.1:9000，回车。结果是控制台里首先打印出http协议的信息。然后就是死循环打印no data。原因可想而知，浏览器在发起http请求后，一定时间没有得到服务器端的相应，便会断开tcp链接。此时channel的read方法就会返回-1。坑的是，链接都已经断开了，Selector还能将它select出来，并且一直是可读状态。这就导致了一直死循环打印no data。如果这种事情发生在生产环境，后果真是不堪设想啊。

　　解决方式虽然比较简单，但却不能疏忽遗漏。当channel的read方法返回-1时。调用channel的close方法关闭channel。上边代码就是在打印no data的地方添加一行：cChannel.close()。这样channel对应的SelectionKey也就不会再被select出来了。也就不再发生死循环了。

一惑

　　NIO编程中我一直有一个疑惑或者说不确定，就是什么时候调用channel的write方法将数据返回给客户端。

　　在网上看到的一些例子代码中无非两种。

直接返回---服务器端读取到客户端发过来的数据后，直接调用channel的write方法将数据返回给客户端。
注册Writable事件，可写事件发生后再返回---服务器读取到客户端发来的数据后，然后将channel注册到selector对Writable感兴趣。当可写后，再调用channel.write写数据。但这个方式一定得注意：当写完数据后，一定取消对Writable事件的感兴趣。否则服务器又得忙到崩溃。

　　这两个方式似乎都可以工作，跑一些例子也都没发现什么问题。但是心里总是感觉有一点不够明确不够开朗（可能就是因为对系统底层的实现不够明确的原因）。Java有一些成熟的开源的NIO框架，比如netty、mina。何不去看看他们是如何处理的呢？好，接下来就看看mina的实现方式。（我这里看的是mina2.0.2版本）

　　接下来是我追踪到AbstractPollingIoProcessor的flushNow方法的代码