关于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模型就能大展身手。