Java NIO之网络编程

最近在研究Java NIO和netty，曾经一度感觉很吃力，根本原因还是对操作系统、TCP/IP、socket编程的理解不到位。

不禁感叹，还是当初逃的课太多。

假如上天给我一次机会，能够再回到意气风发的校园时代，我想那些逃过的课，应该还是会逃。

毕竟在那个躁动的年纪，有很多的事情都比上课有意思。

不扯闲篇了，进入正题。

先重新理解一下socket编程，主要是基于TCP协议。上一张我从《Unix网络编程》里面截取的一张图

通过这张图，能够大概理解socket编程的几个函数功能和调用顺序，更为关键的是可以看出TCP协议的3次握手发生的时机。

但是这张图并没有很好的揭示socket是怎样体现插座、插口的含义，所以我自己斗胆画了一张图，请多多指教。

借着这张图，说几个要点：

1、刚创建出来的socket，其实并没有server和client之分，只是socket调用了listen方法之后，角色才改变，处理逻辑也随之改变

2、client端的socket发送连接请求，server端的socket接收请求后，再创建一个socket与client端的socket传递数据，就像两个插口在通信

3、每个socket都有发送缓存和接收缓存，操作系统可以根据这些缓存来判断socket可读、可写、异常等状态

4、server端的socket保存着2种连接队列，后面还会说到

5、每个socket还会关联一个文件描述符（文件句柄），操作系统通过这个文件描述符（文件句柄）操作socket。图中并未画出。

再来说说Linux的IO多路复用。

Linux的多种IO模型以及select、poll、epoll等的详细介绍，我这里不赘述，主要也是因为段位不够。

我比较关注的是IO多路复用的那些IO事件。先看看jdk里面SelectionKey类里面的几个方法

    public final boolean isReadable() {
        return (readyOps() & OP_READ) != 0;
    }

   public final boolean isWritable() {
        return (readyOps() & OP_WRITE) != 0;
    }

    public final boolean isConnectable() {
        return (readyOps() & OP_CONNECT) != 0;
    }

    public final boolean isAcceptable() {
        return (readyOps() & OP_ACCEPT) != 0;
    }

方法名很简单：可读、可写、可连接、可接收。从socket的缓存判断可读、可写倒是很好理解；可是什么时候socket是可连接或者可接收呢？？？

于是硬着头皮慢慢啃《TCP-IP详解：卷2》，终于找到了一些端倪。不得不说，欠的债迟早是要还的。

下面再引入书中的一段文字：

图 1 6 - 5 2 显 示 了 插 口 的 读 、 写 和 例 外 情 况 。 我 们 将 看 到 s o o _ s e l e c t 使用了 s o r e a d a b l e 和 s o w r i t e a b l e 宏 ， 这 些 宏 在 s y s / s o c k e t v a r . h 中定义。

1. 插口可读吗
1 1 3 - 1 2 0 s o r e a d a b l e 宏的定义如下:

    #define soreadable(so) 
        ((so)->so_rcv.sb_cc >= (so)->so_rcv.sb_lowat || 
        ((so)->so_state & SS_CANTRCVMORE) || 
       (so)->so_qlen || (so)->so_error)

因为 U D P 和 T C P 的 接 收 下 限 默 认 值 为 1 ( 图 1 6 - 4 ) ， 下 列 情 况 表 示 插 口 是 可 读 的 : 接 收 缓 存 中有数据，连接的读通道被关闭，可以接受任何连接或有挂起的差错。

2. 插口可写吗
1 2 1 - 1 2 8 s o w r i t e a b l e 宏的定义如下:

    #define sowriteable(so) 
       (sbspace(&(so)->so_snd) >= (so)->so_snd.sb_lowat && 
        (((so)->so_state&SS_ISCONNECTED) || 
       ((so)->so_proto->pr_flags&PR_CONNREQUIRED)==0) || 
       ((so)->so_state & SS_CANTSENDMORE) || 
        (so)->so_error)

T C P 和 U D P 默 认 的 发 送 低 水 位 标 记 是 2 0 4 8 。对于 U D P 而言， s o w r i t e a b l e 总 是 为 真 ， 因 为 s b s p a c e 总是等于 s b _ h i w a t ， 当 然 也 总 是 大 于 或 等 于 s o _ l o w a t ， 且 不 要 求 连 接 。对于 T C P 而 言 ， 当 发 送 缓 存 中 的 可 用 空 间 小 于 2 0 4 8 个 字 节 时 ， 插 口 不 可 写 。 其 他 的 情 况在图 1 6 - 5 2 中讨论。

3. 还有挂起的例外情况吗

1 2 9 - 1 4 0 对于例外情况，需检查标志 s o _ o o b m a r k 和 S S _ R E C V A T M A R K 。 直 到 进 程 读 完 数 据流中的同步标记后，例外情况才可能存在。 

原来，select调用的底层实现里面，把很多个事件都只是归并进了可读和可写这两种状态。比如在我之前看来，server端的socket已经将连接排队，就代表可连接状态，可是在select看来，这就是可读状态。

有了前面的一些基础，现在上一段Java NIO的代码

        // 创建一个selector
        Selector selector = Selector.open();
        // 创建一个ServerSocketChannel
        ServerSocketChannel servChannel = ServerSocketChannel.open();
        servChannel.configureBlocking(false);
        // 绑定端口号
        servChannel.socket().bind(new InetSocketAddress(8080), 1024);
        // 注册感兴趣事件
        servChannel.register(selector, SelectionKey.OP_ACCEPT);
        
        // select系统调用
        selector.select(1000);
        
        Set<SelectionKey> selectedKeys = selector.selectedKeys();
        Iterator<SelectionKey> it = selectedKeys.iterator();
        SelectionKey key = null;
        while (it.hasNext()) {
            key = it.next();
            it.remove();
            if (key.isValid()) {
                // 处理新接入的请求消息
                if (key.isAcceptable()) {
                    ServerSocketChannel ssc = (ServerSocketChannel) key.channel();
                    // 接收客户端的连接，并创建一个SocketChannel
                    SocketChannel sc = ssc.accept(); 
                    sc.configureBlocking(false);
                    // 将SocketChannel和感兴趣事件注册到selector
                    sc.register(selector, SelectionKey.OP_READ); 
                }
                if (key.isReadable()) {
                    // 读数据的处理
                }
            }
        }            

分析这段代码之前，先搞清楚selector、SelectionKey、pollArray等几个数据结构以及相互持有关系。

pollArray干的是数组的活，但是并不是一个直接的数组。

selector诞生的时候，随之关联了一块内存（pollArray），然后用unsafe类来小心翼翼的按字节顺序写入数据，最终实现了数组结构的功能。这种看似怪异的实现方式，应该是处于效率的考虑吧。

selector并没有直接持有pollArray，而是持有一个pollArray的封装类PollArrayWrapper的引用。

    // The poll fd array
    PollArrayWrapper pollWrapper; // 在selector的父类里面

    // The set of keys with data ready for an operation
    protected Set<SelectionKey> selectedKeys;

selectedKeys是一个集合，代表poll系统调用后返回的所有就绪事件，里面存放的数据结构是SelectionKey。

    final SelChImpl channel;                            // package-private
    public final SelectorImpl selector;

    // Index for a pollfd array in Selector that this key is registered with
    private int index; // pollArray里面的索引值，保存在这里是方便实现数组操作

    private volatile int interestOps; // 注册的感兴趣事件掩码
    private int readyOps; // 就绪事件掩码

SelectionKey不但持有channel，还持有selector；interestOps、readyOps与pollArray里面的eventOps、reventOps对应。

Java定义了一些针对文件描述符的事件，其实也是对底层操作系统poll定义的事件的一个映射。事件用掩码来表示，非常方便进行位操作。如下：

    public static final short POLLIN       = 0x0001; // 文件描述符可读
    public static final short POLLOUT      = 0x0004; // 文件描述符可写
    public static final short POLLERR      = 0x0008; // 文件描述符出现错误
    public static final short POLLHUP      = 0x0010; // 文件描述符挂断
    public static final short POLLNVAL     = 0x0020; // 文件描述符不对
    public static final short POLLREMOVE   = 0x0800; // 文件描述符移除

    @Native static final short POLLCONN   = 0x0002; // 可连接

我记得POLLCONN在之前的版本中直接被赋值成POLLOUT，这里改成了0x0002，这里我是真不知道为什么。希望高手来回复一下。

最终这些事件都会传递到内核的poll系统调用，去监控所有传递给poll的文件描述符。

回到之前的NIO代码

1、先看看 servChannel.register(selector, SelectionKey.OP_ACCEPT) 是如何实现注册的

一路调用后，会到一个关键方法

    protected final SelectionKey register(AbstractSelectableChannel ch,
                                          int ops,
                                          Object attachment)
    {
        if (!(ch instanceof SelChImpl))
            throw new IllegalSelectorException();
        SelectionKeyImpl k = new SelectionKeyImpl((SelChImpl)ch, this);
        k.attach(attachment);
        synchronized (publicKeys) {
            implRegister(k); // 这一步把channel的文件描述符fd添加到pollArray（见上图）
        }
        k.interestOps(ops); // 这一步把感兴趣事件eventOps添加到pollArray（见上图）
        return k;
    }

具体的逻辑肯定比注释要复杂。接下来看看pollArray的内存操作，以添加文件描述符fd为例

    void putDescriptor(int i, int fd) {
        int offset = SIZE_POLLFD * i + FD_OFFSET;
        pollArray.putInt(offset, fd);
    }

    final void putInt(int offset, int value) {
        unsafe.putInt(offset + address, value);
    }

最终还是用unsafe直接修改内存

2、再看看最核心的selector.select(1000)。次方法最终调用doSelect方法，而doSelect方法的实现有多种，我们就以poll版本进行探秘

    // 做了很多删减
    protected int doSelect(long timeout)
        throws IOException
    {
        // 执行最核心的poll系统调用
        pollWrapper.poll(totalChannels, 0, timeout);
        // 将到来的就绪事件更新保存
        int numKeysUpdated = updateSelectedKeys();
        return numKeysUpdated;
    }

poll系统调用会把用户空间的线程挂起，也就是阻塞调用，timeout指定多长时间后必须返回。

updateSelectedKeys方法根据poll返回的channel就绪事件，去更新pollArray对应fd的reventOps（见上图），以及selector的selectedKeys。

    /**
     * Copy the information in the pollfd structs into the opss
     * of the corresponding Channels. Add the ready keys to the
     * ready queue.
     */
    protected int updateSelectedKeys() {
        int numKeysUpdated = 0;
        // Skip zeroth entry; it is for interrupts only
        for (int i=channelOffset; i<totalChannels; i++) {
            // 得到就绪事件的掩码
            int rOps = pollWrapper.getReventOps(i);
            if (rOps != 0) {
                SelectionKeyImpl sk = channelArray[i];
                pollWrapper.putReventOps(i, 0); // 重置为0，即为未就绪
                if (selectedKeys.contains(sk)) {
                    // 把事件的掩码翻译成SelectionKey中定义的操作（OP_READ,OP_WRITE,OP_CONNECT,OP_ACCEPT）
                    if (sk.channel.translateAndSetReadyOps(rOps, sk)) {
                        numKeysUpdated++;
                    }
                } else {
                    sk.channel.translateAndSetReadyOps(rOps, sk);
                    if ((sk.nioReadyOps() & sk.nioInterestOps()) != 0) {
                        // 更新selectedKeys
                        selectedKeys.add(sk);    
                        numKeysUpdated++;
                    }
                }
            }
        }
        return numKeysUpdated;
    }
            

把就绪事件的掩码进行翻译，感觉就像是Java做的一层适配，让我们用户不用去关注事件掩码等细节

看一下实现这一逻辑的一段代码，在ServerSocketChannel类里面：

/**
     * Translates native poll revent set into a ready operation set
     */
    public boolean translateReadyOps(int ops, int initialOps,
                                     SelectionKeyImpl sk) {
        int intOps = sk.nioInterestOps(); // Do this just once, it synchronizes
        int oldOps = sk.nioReadyOps();
        int newOps = initialOps;

        if ((ops & PollArrayWrapper.POLLNVAL) != 0) {
            // This should only happen if this channel is pre-closed while a
            // selection operation is in progress
            // ## Throw an error if this channel has not been pre-closed
            return false;
        }

        if ((ops & (PollArrayWrapper.POLLERR
                    | PollArrayWrapper.POLLHUP)) != 0) {
            newOps = intOps;
            sk.nioReadyOps(newOps);
            return (newOps & ~oldOps) != 0;
        }
        // 这里将可连接当作可读来看待的
        if (((ops & PollArrayWrapper.POLLIN) != 0) &&
            ((intOps & SelectionKey.OP_ACCEPT) != 0))
                newOps |= SelectionKey.OP_ACCEPT;

        sk.nioReadyOps(newOps);
        return (newOps & ~oldOps) != 0;
    }

通过上面的分析，大概有了一个清晰的思路：

Java NIO主要是基于底层操作系统提供的的IO多路复用功能，比如Linux下的select/poll、epoll等系统调用。Java层面为每个selector开辟了一块内存，用来保存用户注册的所有channel、所有感兴趣事件，并最终当作参数传递给底层的系统调用，最后将内核返回的结果封装成selectedKeys等数据结构。