Java NIO 随笔_nio poll0(-CSDN博客

本文链接：https://blog.csdn.net/qyp199312/article/details/78743793

前言
Java NIO 和 BIO的区别
Selector 的工作模式
- Selector的工作流程图
- 通用的NIO Socket的编写方式
Selector 在 SocketChannel 上的通讯流程
- NIO 与 BIO 的比较
- NIO的Socket通讯时序图

前言

最近在看Java NIO，做下记录。操作平台皆基于Windows 10， JDK8, TCP Socket.
记录里面把普通IO 成为 BIO。

记录提纲：

Java NIO的设计模式
Selector的阻塞原理
ServerSocketChannel的TCP通讯流程

Java NIO 和 BIO的区别

编辑方式的区别

Java BIO是基于流的，一旦收到消息就会立马处理，但是存在等到流收取事件。 NIO是基于channel的，操作系统内核协助获取完毕数据流之后才会交给业务代码处理。

以Socket为例：

普通IO：

//1、创建一个服务器端Socket，即ServerSocket，指定绑定的端口，并监听此端口
ServerSocket serverSocket =newServerSocket(10086);//1024-65535的某个端口
//2、调用accept()方法开始监听，等待客户端的连接
Socket socket = serverSocket.accept();
//3、获取输入流，并读取客户端信息
InputStream is = socket.getInputStream();
...
socket.shutdownInput();//关闭输入流
//4、获取输出流，响应客户端的请求
OutputStream os = socket.getOutputStream();
...
//5、关闭资源
...
serverSocket.close();

NIO：

Selector selector = Selector.open();
// 打开监听信道 
ServerSocketChannel listenerChannel = ServerSocketChannel.open();
// 与本地端口绑定
listenerChannel.socket().bind(new InetSocketAddress(12345));
// 设置为非阻塞模式
listenerChannel.configureBlocking(false);
// 将选择器绑定到监听信道,只有非阻塞信道才可以注册选择器.并在注册过程中指出该信道可以进行Accept操作
listenerChannel.register(selector, SelectionKey.OP_ACCEPT);

// 反复循环,等待IO
while (true) {
    // 等待某信道就绪(或超时)
    if (selector.select(TIME_OUT) == 0) {
        continue;
    }
    // 取得迭代器.selectedKeys()中包含了每个准备好某一I/O操作的信道的SelectionKey
    Iterator<SelectionKey> keyIter = selector.selectedKeys().iterator();
    while (keyIter.hasNext()) {
        SelectionKey key = keyIter.next();
        // 处理信息
        dealWith(key);
        // 移除处理过的键
        keyIter.remove();
    }
}

可以看出, BIO需要获取到输入输出流，阻塞性的进行输入输出操作。
而NIO则使用了Selector，这个Selector可以绑定多个 Chanel，例如实现TCP、UDP、File的操作，灵活性更高。

BIO的通讯模型

对于BIO而已，不同的IO类型处理的事件是不一样的，比如写TCP处理就必须使用ServerSocket, 读写文件处理则必须使用InputStream/OutputStream等。

由于BIO的通讯模型中所有的操作都是阻塞式的，因此为了实现对多客户端的处理，则必须频繁的创建大量的线程来针对每一个连接进行处理。

Java Socket编程----通信是这样炼成的
图片来源: Java Socket编程—-通信是这样炼成的

BIO通讯模型在少量请求、高数据流的情况下处理非常有效。但是针对于大量请求、低数据流的情况，就面临着这样的问题：

大量客户端连接，则需要建立大量的线程处理。线程的创建、销毁、上下文切换开销巨大。
流式读取, 每次从内核空间将字节拷贝到线程空间，处理完毕之后再交给内核空间取发送，有IO开销。
阻塞式IO，在网络环境较差的情况下，线程的read()/write()方法是阻塞的，线程周期长，线程调度会占据较多时间。
如上述，如果在流式读取中，每次 read()或者write()还做一些其它的业务操作，线程调度将会占据更多的时间。
在使用线程池的情况下，高并发，低数据量的IO请求，可能导致内核空间大量请求堆积。

NIO的通讯模型刚好就解决掉了上述的问题。

NIO的通讯模型

NIO面向事件而设计。由 Selector进行监听和分发。每一个处理Chanel在向Selector注册的时候必须选定监听的事件。
Java NIO：浅析I/O模型

图片来源：Java NIO：浅析I/O模型

具体流程可以浅析为：

各种Chanel(TCP/UDP/File)向Selector注册(一般只会写一种类型,否则代码的可编辑性很低)。
Selector根据不同的内核空间事件通知对不同的Channel进行调度。
Channel的处理面向缓冲区，通过建立堆外内存将待处理数据写入缓冲区内。
缓冲区写结束了之后Channel才会继续处理。Selector在这一系列操作中并不阻塞。

Selector 的工作模式

Selector的工作流程图

Selector除了在获取内核通知的时候，其它时候都不阻塞。见文章：Java NIO——Selector机制源码分析—转

下图是Selector调用内部类 SubSelector 的调用时序图。其中 poll0() 方法是一个本地方法。它的作用是在一个等待时间段里面，如果有注册好的Channel的IO事件则立即返回，否则等到等待时间之后返回。

如上所述，在poll0() 中会将当前等待时间段里面所监听到的所有的IO句柄进行归类分集，并根据数量的不同生成不同数量的线程，生成SelectKey再交给业务代码处理。需要注意的是，在没有使用独立线程/线程池去处理每个SelectKey的情况下， NIO是依然同步的

通用的NIO Socket的编写方式

通常的NIO Socket会这么编写：

{
    Selector selector = Selector.open();
    // 打开监听信道 目前只做TCP支持
    ServerSocketChannel listenerChannel = ServerSocketChannel.open();
    // 与本地端口绑定
    listenerChannel.socket().bind(new InetSocketAddress(ListenPort));
    // 设置为非阻塞模式
    listenerChannel.configureBlocking(false);
    // 将选择器绑定到监听信道,只有非阻塞信道才可以注册选择器.并在注册过程中指出该信道可以进行Accept操作
    listenerChannel.register(selector, SelectionKey.OP_ACCEPT);
    // 反复循环,等待IO
    while (true) {
        // 等待某信道就绪(或超时)
        if (selector.select(TIME_OUT) == 0) {
            continue;
        }
        // 取得迭代器.selectedKeys()中包含了每个准备好某一I/O操作的信道的SelectionKey
        Iterator<SelectionKey> keyIter = selector.selectedKeys().iterator();

        while (keyIter.hasNext()) {
            SelectionKey key = keyIter.next();
            try {
                if (key.isAcceptable()) {
                    /*clientChannel.register(key.selector(), SelectionKey.OP_READ, ByteBuffer.allocate(bufferSize));*/
                    protocol.handleAccept(key);
                }

                if (key.isReadable()) {
                    /*key.interestOps(SelectionKey.OP_READ | SelectionKey.OP_WRITE);*/
                    protocol.handleRead(key);
                }

                if (key.isValid() && key.isWritable()) {
                    protocol.handleWrite(key);
                }
            } catch (IOException ex) {
            }
            // 移除处理过的键
            keyIter.remove();
        }
    }
}

可是，这么编写的原因是什么呢？

首先， ServerSocketChannel是只支持SelectionKey.OP_ACCEPT的(见ServerSocketChannel#validOps)。这样的设计就是专为TCP连接而设定的。

其次，对于SocketChannel，它支持SelectionKey.OP_READ | SelectionKey.OP_WRITE | SelectionKey.OP_CONNECT。这种设计就表示它专门用于处理ServerSocketChannel产生的连接信息，然后对其进行读写操作。

再次，因为Selector在最初注册的时候，根本不知道有没有链接会到来，会在什么时候到来。因此必须由代码手动注册SocketChannel给Selector, 它才知道对每个不同的SocketChannel进行处理(注意Selector本身是没有显式的提供移除Channel功能的)。

继续，如果在key.isAcceptable()代码块里没有做SelectionKey.OP_READ，将会导致key.isReadable()返回值为false。同样的，对于一个既定的Channel而言，想要修改它在Selector上注册的操作类型，需要调用key.interestOps()方法去修改。它会让Selector重新生成一条事件通知。

最后，NIO Servlet用于处理事件处理的线程只有一个。其包含不限个数(一般是3~5个)的子线程，专用于从操作系统获取事件信息及数据发送。

如上。普通NIO的编写模式大多大同小异。都是通过ServerSocketChannel获取SocketChannel，并向Selector注册。然后由独立的业务代码进行处理。可以理解为用一个线程去处理所有的请求。如果想要使用多线程去处理，可以使用多个Selector，再配合线程池。这样效率会有大幅度的提升(需要注意每个Selector都会向自己注册的Channel发起通知，业务代码需要判断“SocketChannel是否已经被其它代码处理了)。