关于nio:NIO优化原理和Tomcat线程模型

1、I/ O 阻塞

书上说 BIO、NIO 等都属于 I / O 模型，然而 I / O 模型这个范畴有点含混，我为此走了不少弯路。咱们日常开发过程中波及到 NIO 模型利用，如 Tomcat、Netty 中等线程模型，能够间接将其视为 网络 I / O 模型。本文还是在根底篇章中介绍几种 I / O 模型形式，前面就默认只解说网络 I / O 模型了。

1.1、I/ O 分类

BIO、NIO、AIO 等都属于 I / O 模型，所以它们优化的都是零碎 I / O 的性能，因而首先，咱们要分明常见的 I / O 有哪些分类：

1.2、I/ O 过程和性能

I/O(Input/Output)即数据的输出 / 输入，为什么大家很关怀 I / O 的性能呢？因为 I / O 存在的范畴很广，在高并发的场景下，这部分性能会被有限放大。而且与业务无关，是能够有对立解决方案的。

所有的零碎 I / O 都分为两个阶段：期待就绪和数据操作。举例来说，读函数，分为期待零碎可读和真正的读；同理，写函数分为期待网卡能够写和真正的写：

1. 期待就绪 ：期待数据就绪，个别是将数据加载到 内核缓存区。无论是从磁盘、网络读取数据，程序能解决的都是进入内核态之后的数据，在这之前，cpu 会阻塞住，期待数据进入内核态。
2. 数据操作 ：数据就绪后，个别是将内核缓存中的数据加载到 用户缓存区。

须要阐明的是期待就绪的阻塞是不应用 CPU 的，是在“空等”；而真正的读写操作的阻塞是应用 CPU 的，真正在”干活”，而且这个过程十分快，属于 memory copy，带宽通常在 1GB/ s 级别以上，能够了解为根本不耗时。这就呈现一个奇怪的景象 — 不应用 CPU 的“期待就绪”，却比理论应用 CPU 的“数据操作”，占用 CPU 工夫更多。

传统阻塞 I / O 模型，即在读写数据过程中会产生阻塞景象。当用户线程收回 I / O 申请之后，内核会去查看数据是否就绪，如果没有就绪就会期待数据就绪，而用户线程就会处于阻塞状态，用户线程交出 CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回后果给用户线程，用户线程才会解除 block 状态。

明确的是，让当前工作线程阻塞，期待数据就绪，是很节约线程资源的事件，上述三种 I / O 都有肯定的优化计划：

• 磁盘 I /O：古代电脑中都有一个 DMA(Direct Memory Access 间接内存拜访) 的外设组件，能够将 I / O 数据间接传送到主存储器中并且传输不须要 CPU 的参加，以此将 CPU 解放出来去实现其余的事件。
• 网络 I /O：NIO、AIO 等 I / O 模型，通过向事件选择器注册 I / O 事件，基于就绪的事件来驱动执行 I / O 操作，防止的期待过程。
• 内存 I /O：内存局部没波及到太多阻塞，优化点在于缩小用户态和内核态之间的数据拷贝。nio 中的零拷贝就有 mmap 和 sendfile 等实现计划。

1.3、网络 I / O 阻塞

这里认真的讲讲网络 I / O 模型中的阻塞，即 socket 的阻塞。在计算机通信畛域，socket 被翻译为“套接字”，它是计算机之间进行通信的一种约定或一种形式，是在 tcp/ip 协定上，形象进去的一层网络通讯协定。

同下面 I / O 的过程一样，网络 I / O 也同样分成两个局部：

1. 期待网络数据达到网卡，读取到内核缓冲区。
2. 从内核缓冲区复制数据到用户态空间。

每个 socket 被创立后，都会调配两个缓冲区，输出缓冲区和输入缓冲区：

• 输出缓冲区：当应用 read()/recv() 读取数据时，（1）首先会查看缓冲区，如果缓冲区中有数据，那么就读取，否则函数会被阻塞，直到网络上有数据到来。（2）如果要读取的数据长度小于缓冲区中的数据长度，那么就不能一次性将缓冲区中的所有数据读出，残余数据将一直积压，直到有 read()/recv() 函数再次读取。（3）直到读取到数据后 read()/recv() 函数才会返回，否则就始终被阻塞。
• 输入缓冲区：当应用 write()/send() 发送数据时，（1）首先会查看缓冲区，如果缓冲区的可用空间长度小于要发送的数据，那么 write()/send() 会被阻塞（暂停执行），直到缓冲区中的数据被发送到指标机器，腾出足够的空间，才唤醒 write()/send() 函数持续写入数据。（2）如果 TCP 协定正在向网络发送数据，那么输入缓冲区会被锁定，不容许写入，write()/send() 也会被阻塞，直到数据发送结束缓冲区解锁，write()/send() 才会被唤醒。（3）如果要写入的数据大于缓冲区的最大长度，那么将分批写入。（4）直到所有数据被写入缓冲区 write()/send() 能力返回。

由此可见在网络 I / O 中，会有很多的因素导致数据的读取和写入过程呈现阻塞，创立 socket 连贯也一样。socket.accept()、socket.read()、socket.write()这类函数都是同步阻塞的，当一个连贯在解决 I / O 的时候，零碎是阻塞的，该线程以后的 cpu 工夫片就节约了。

2、阻塞优化

2.1、BIO、NIO、AIO

BIO、NIO、AIO 比照

以 socket.read()为例子：

• 传统的 BIO 外面 socket.read()，如果 TCP RecvBuffer 里没有数据，函数会始终阻塞，直到收到数据，返回读到的数据。
• 对于 NIO，如果 TCP RecvBuffer 有数据，就把数据从网卡读到内存，并且返回给用户；反之则间接返回 0，永远不会阻塞。
• 最新的 AIO(Async I/O)外面会更进一步：岂但期待就绪是非阻塞的，就连数据从网卡到内存的过程也是异步的。

换句话说，BIO 里用户最关怀“我要读”，NIO 里用户最关怀”我能够读了”，在 AIO 模型里用户更须要关注的是“读完了”。

NIO

NIO 的优化体现在两个方面：

1. 网络 I / O 模式 的优化，通过非阻塞的模式，进步了 CPU 的使用性能。
2. 内存 I /O的优化，零拷贝等形式，让数据在内核态和用户态之前的传输耗费升高了。

NIO 一个重要的特点是：socket 次要的读、写、注册和接管函数，在期待就绪阶段都是非阻塞的，真正的 I / O 操作是同步阻塞的（耗费 CPU 但性能十分高）。

NIO 的次要事件有几个：读就绪、写就绪、有新连贯到来。

咱们首先须要注册当这几个事件到来的时候所对应的处理器。而后在适合的机会通知事件选择器：我对这个事件感兴趣。对于写操作，就是写不进来的时候对写事件感兴趣；对于读操作，就是实现连贯和零碎没有方法承载新读入的数据的时；对于 accept，个别是服务器刚启动的时候；而对于 connect，个别是 connect 失败须要重连或者间接异步调用 connect 的时候。

其次，用一个死循环抉择就绪的事件，会执行零碎调用（Linux 2.6 之前是 select、poll，2.6 之后是 epoll，Windows 是 IOCP），还会阻塞的期待新事件的到来。新事件到来的时候，会在 selector 上注册标记位，标示可读、可写或者有连贯到来。

2.2、Reactor 模式

Reactor 模式称之为响应器模式，通常用于 NIO 非阻塞 IO 的网络通信框架中。Reactor 设计模式用于解决由一个或多个客户端并发传递给应用程序的的服务申请，能够了解成，Reactor 模式是用来实现网络 NIO 的形式。

Reactor 是一种事件驱动机制，是解决并发 I / O 常见的一种模式，用于同步 I /O，其中心思想是将所有要解决的 I / O 事件注册到一个核心 I / O 多路复用器上，同时主线程阻塞在多路复用器上，一旦有 I / O 事件到来或是准备就绪，多路复用器将返回并将相应 I / O 事件散发到对应的处理器中。

Reactor 模式次要分为上面三个局部：

1. 事件接收器 Acceptor：次要负责接管申请连贯，接管申请后，会将建设的连贯注册到分离器中。
2. 事件分离器 Reactor：依赖于循环监听多路复用器 Selector，是阻塞的，一旦监听到事件，就会将事件散发到事件处理器。（例如：监听读事件，等到内核态数据就绪后，将事件散发到 Handler，Handler 将数据读到用户态再做解决）
3. 事件处理器 Handler：事件处理器次要实现相干的事件处理，比方读写 I / O 操作。

2.3、三种 Reactor 模式

单线程 Reactor 模式

一个线程：

• 单线程：建设连贯（Acceptor）、监听 accept、read、write 事件（Reactor）、处理事件（Handler）都只用一个单线程。

多线程 Reactor 模式

一个线程 + 一个线程池：

• 单线程：建设连贯（Acceptor）和 监听 accept、read、write 事件（Reactor），复用一个线程。
• 工作线程池：处理事件（Handler），由一个工作线程池来执行业务逻辑，包含数据就绪后，用户态的数据读写。

主从 Reactor 模式

三个线程池：

• 主线程池：建设连贯（Acceptor），并且将 accept 事件注册到从线程池。
• 从线程池：监听 accept、read、write 事件（Reactor），包含期待数据就绪时，内核态的数据 I 读写。
• 工作线程池：处理事件（Handler），由一个工作线程池来执行业务逻辑，包含数据就绪后，用户态的数据读写。

3、Tomcat 线程模型

3.1、Api 网络申请过程

咱们先补一下基础知识，解说后端接口的响应过程。一个 http 连贯里，残缺的网络处理过程个别分为 accept、read、decode、process、encode、send 这几步：

1. accept：接管客户端的连贯申请，创立 socket 连贯（tcp 三次握手，创立连贯）。
2. read：从 socket 读取数据，包含期待读就绪，和理论读数据。
3. decode：解码，因为网络上的数据都是以 byte 的模式进行传输的，要想获取真正的申请，必然须要解码。
4. process：业务解决，即服务端程序的业务逻辑实现。
5. encode：编码，同理，因为网络上的数据都是以 byte 的模式进行传输的，也就是 socket 只接管 byte，所以必然须要编码。
6. send：往网络 socket 写回数据，包含理论写数据，和期待写就绪。

3.2、各个线程模型

在 tomcat 的各个版本中，所反对的线程模型也产生了一步步演变。一方面，间接将默认线程模型，从 BIO 变成了 NIO。另一方面，在后续几个版本中，退出了对 AIO 和 APR 线程模型的反对，这里要留神，仅仅是反对，而非默认线程模型。

• BIO：阻塞式 IO，tomcat7 之前默认，采纳传统的 java IO 进行操作，该模式下每个申请都会创立一个线程，实用于并发量小的场景。
• NIO：同步非阻塞，比传统 BIO 能更好的反对大并发，tomcat 8.0 后默认采纳该模式。
• AIO：异步非阻塞 (NIO2)，tomcat8.0 后反对。多用于连贯数目多且连贯比拟长（重操作）的架构，比方相册服务器，充沛调用 OS 参加并发操作，编程比较复杂。
• APR：tomcat 以 JNI 模式调用 http 服务器的外围动态链接库来解决文件读取或网络传输操作，须要编译装置 APR 库（也就是说 IO 操作的局部间接调用 native 代码实现）。

各个线程模型中，NIO 是作为目前最实用的线程模型，因而也是目前 Tomcat 默认的线程模型，因而本文对此着重解说。

3.3、BIO 和 NIO

BIO 模型

在 BIO 模型中，次要参加的角色有：Acceptor和Handler 工作线程池。对应于前文中 Api 的申请过程，它们的分工如下：

• Acceptor：Accepter 线程专门负责建设网络连接（accept）。新连贯创立后，交给 Handler 工作线程池解决申请。
• Handlers：针对每个申请的连贯，Handler 工作线程池都会调配一个线程，执行前面的所有步骤（read、decode、process、encode、send）。

前文的知识点有铺垫，read和 send 是面向网络 I / O 的，在期待读写就绪过程中，其实是 CPU 阻塞的。因而 Handler 工作线程池中的每个线程，都会因为 I / O 阻塞而“空期待”，造成节约。

NIO 模型

tomcat 的 NIO 模型，相比拟于 BIO 模型，多了个 Poller 角色：Acceptor、Poller和 Handler 工作线程池。这三个角色是不是很相熟，如果将 Poller 换成 Reactor，是不是就是 Reactor 模型。没错，tomcat 的 nio 模型，确实就是基于 主从 Reactor 模型，只不过将 Reactor 换了个名字而已。

• Acceptor：Accepter 线程专门负责建设网络连接（accept）。新连贯创立后，不是间接应用 Worker 线程解决申请，而是先将申请发送给 Poller 缓冲队列。
• Poller：在 Poller 中，保护了一个 Selector 对象，当 Poller 从缓冲队列中取出连贯后，注册到该 Selector 中，阻塞期待读写就绪（read 期待就绪、send 期待就绪）。
• Handlers：遍历 Selector，找出其中就绪的 IO 操作，并交给 Worker 线程解决（read 内存读、decode、process、encode、send 内存写）。

比照

• BIO 模型中，一个线程对应一个申请连贯的残缺过程，因而 tomcat 服务能解决的最大连接数，和最大线程数统一。
• NIO 模型中，在一个申请连贯中，对应的一个工作线程，只解决 I / O 读写就绪后的非阻塞过程。因而 tomcat 服务能解决的最大连接数，要远大于最大线程数量。

3.4、参数设置

针对于 tomcat 的 nio 模型，能够做一些参数设置。因为 springboot 是内嵌 tomcat 的，这些参数设置同样能够在 properties 配置文件中定义：

• 最大线程数（server.tomcat.threads.max）：工作线程池的最大线程数，默认 200。留神不是越大越好，如果线程数过大，那么 CPU 会破费大量的工夫用于线程的切换，整体效率会升高。
• 最小线程数（server.tomcat.threads.min-spare）：工作线程池的最小线程数，默认 10。
• 最大期待数（server.tomcat.accept-count）：当调用 HTTP 申请数达到 tomcat 的最大线程数时，还有新的 HTTP 申请到来，这时 tomcat 会将该申请放在期待队列中，这个 acceptCount 就是指可能承受的最大期待数，默认 100。如果期待队列也被放满了，这个时候再来新的申请就会被 tomcat 回绝。
• 最大连接数（server.tomcat.max-connections）：在同一时间，tomcat 可能承受的最大连接数，默认 8192。

4、常见问题

1、tomcat 运行后，呈现 nio-8080-exec-前缀的线程作用是什么？

是工作线程池中的线程。你们能够察看某个 springboot 运行我的项目的线程模型，因为根本都是基于 nio 模型的 tomcat 利用，因而都包含这些线程：

• 1 个名称中蕴含 Accepter 的线程。
• 2 个名称中蕴含 Poller 的线程。
• 10 个工作线程，名称从 nio-8080-exec-1 到 nio-8080-exec-10。如果并发交高，默认最多有 200 个线程，名称到 nio-8080-exec-200。

2、tomcat 中 nio 模型中，存在 poller 单线程读取多个申请线程的数据，会不会呈现线程平安问题？因为通过会应用 ThreadLocal 存储申请用户身份信息。

不会。因为 poller 只是解决期待读就绪的环节，一旦读就绪事件触发后，真正的读取数据和解决业务逻辑，都是由工作线程池中的某个线程跟到底，能够放心大胆应用 ThreadLocal。

3、为什么我本人比照测试 nio 和 bio，性能晋升不大？

nio 线程模型优化的是线程利用率，为了在高并发场景下，基于无限的线程资源，解决更多的申请连贯。

例如：tomcat 应用默认最大线程数 200，但你的并发申请数量连 200 都不到，就算是 BIO 模型，线程池中 200 个线程都没利用完。这时候你用 NIO 还是 BIO，区别不大，甚至 BIO 模型解决还更快一些。但如果你的并发申请数到了 2000、20000，BIO 模型就会呈现性能瓶颈了，超过 200 的申请都会阻塞住，而 NIO 模型就能大展身手。