面试｜一文搞定JAVA的网络IO模型

vlambda
2020-06-12

面试｜一文搞定JAVA的网络IO模型

1，最原始的BIO模型

该模型的整体思路是有一个独立的Acceptor线程负责监听客户端的链接，它接收到客户端链接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的一请求一应答的通讯模型。

该模型的最大问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程数和客户端并发访问数呈现1:1的正比关系，由于线程是Java虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统性能将极具下降，随着并发访问量的继续增大，系统会发生线程对栈溢出、创建新线程失败等问题，并最终导致进程宕机或者僵死，不能对外提供服务。

2，伪异步IO，改进版BIO

相对于BIO该方式做了两点改进:

采用线程池代替原来的一个连接对应一个线程的后端处理模型。
增加了一个任务队列。

具体过程就是，当有新的客户端请求接入的时候，将客户端的Socket封装成一个task（实现Runnable接口）投递到任务队列里面，然后由线程池去处理。由于任务队列的大小和线程池的线程数目都是可控的，因此，它的资源占用是可控的，无论多少个客户端并发访问，都不会导致资源耗尽和宕机。

该方式最终也还没有从根本上解决通信线程阻塞的问题。

3，NIO模型

NIO模型是在JDK1.4开始引入的，弥补了原来同步阻塞IO的不足。要了解IO就要彻底搞明白几个概念。

A),缓冲区Buffer

在面向流的IO中，可以将数据直接写入或者将数据直接督导Stream对象中。在NIO库中，所有的数据都是用缓冲区进行处理的。在读数据时，它是直接读到缓冲区中的;在写数据时，写入到缓冲区中。任务和访问NIO中的数据，都是通过缓冲区进行操作的。Java NIO 有以下Buffer类型:

ByteBuffer
MappedByteBuffer
CharBuffer
DoubleBuffer
FloatBuffer
IntBuffer
LongBuffer
ShortBuffer

1),通道Channel

Channel是一个通道，网络数据通过Channel读取和写入。通道和流的不同之处在于通道是双向的，流只是在一个方向上移动(一个流必须是InputStream或者OutputStream的子类)，而且通道可以用于读、写或者同时用于读写。

2),多路复用器Selector

多路复用器提供选择已经就绪的任务的能力。简单来讲，Selector会不断地轮训注册在其上的Channel，如果某个Channel上面有新的TCP链接接入、读和写事件，这个Channel就处于就绪状态，会被Selector轮询出来，然后通过SelectionKey可以获取就绪Channel的集合，进行后续的IO操作。先前的实现是基于select，有句柄数目限制1024，后面NIO2.0改成了epoll(AIO)就突破了最大链接句柄限制。异步通道提供两种方式获取结果：

1),通过java.util.concurrent.Future类来表示异步操作的结果;

2),在执行异步操作的时候传入一个java.nio.channels。由CompletionHandler接口的实现类作为操作完成的回调。

NIO2.0的异步套接字是真正的异步非阻塞IO，它对应UNIX网络编程中的事件驱动IO(AIO)，它不需要通过多路复用器(selector)对注册的通道进行轮询操作即可实现异步读写，从而简化了NIO的编程模型。

NIO服务端及客户端通讯时序图如下

4，Reactor线程模型

1),Reactor单线程模型

由于Reactor模式使用的是异步非阻塞IO，所有操作都不会导致阻塞，理论上一个线程可以独立处理所有IO相关的操作。从架构层面来看，一个NIO线程确实完全可以承担起职责。例如，通过Acceptor类接收客户端的TCP链接请求消息，当链路建立成功之后，通过Dispatch将对应的ByteBuffer派发给指定的Handler上进行编解码。用户线程消息编码后通过NIO线程将消息发送给客户端。不适合，高负载，大并发的应用场景，主要原因如下:

A),一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便NIO线程的CPU负荷达到100%，也无法满足海量消息的编码、解码、读取和发送。

B),当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端链接超时，超时之后往往会进行重发，这更加重了NIO线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈。

C),可靠性问题:一旦NIO线程意外跑飞，或者进入死循环，会导致整个系统通讯模块不可用，不能接受和处理外部消息，造成节点故障。

2),Reactor多线程模型

Reactor多线程模型有以下特点:

A),有一个NIO线程-Acceptor线程用于监听服务端，接受客户端的TCP链接请求。

B),网络IO操作---读写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送。

C),一个NIO线程可以同时处理N条链路，但是一个链路只对应一个NIO线程，防止并发操作问题。

在绝大多数场景下，Reactor多线程模型可以满足性能需求。但是，在个别特殊场景中，一个NIO线程负责监听和处理所有客户端链接可能会存在性能问题。例如并发百万客户端链接，或者服务端需要多客户端握手进行安全认证，但是认证本身非常损耗性能。在这种场景下，单独一个Acceptor线程可能会存在性能不足的问题，为了解决性能问题，产生了第三种Reactor线程模型---主从Reactor多线程模型。

3)，Reactor主从多线程模型

主要特点是:服务端用于接收客户端链接不再是一个单独的NIO线程，而是一个独立的NIO线程池。Acceptor接收到客户端TCP链接请求并处理完成后(可能包含接入认证等)，将新创建的SocketChannel注册到IO线程池(sub reactor线程池)的某个IO线程上，由它负责SocketChannel的读写和编码工作。Acceptor线程池仅仅用于客户端的登录、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作。

5，netty的线程模型

Netty框架的主要线程模型就是IO线程，线程模型设计的好坏，决定了系统的吞吐量、并发性和安全性等架构质量属性。

Netty的线程模型被精心的设计，即提升了框架的并发性能，又能在很大程度避免锁，局部实现了无锁化设计。

Netty的线程模型并不是一成不变的，它实际取决于用户的启动参数配置。通过设置不同的启动参数，Netty可以同时支持Reactor单线程模型，多线程模型和主从Reactor多线程模型。

服务启动的时候，会创建两个NioEventLoopGroup，它们实际是两个独立的 Reactor 线程池。一个用于接收客户端的 TCP 链接，另一个用于处理 IO 相关的读写操作，或者执行系统 Task 、定时任务 Task 等。

Netty用于接收客户端请求的线程池职责如下:

1),接收客户端TCP链接，初始化Channel参数;

2),将链路状态变更时间通知给ChannelPipeLine。

Netty处理IO操作的Reactor线程池职责如下:

1),异步读取通讯端的数据报，发送读事件到ChannelPipeLine

2),异步发送消息到通信对端，调用ChannelPipeLine的消息发送接口

3),执行系统调用Task

4),执行定时任务Task，例如链路空闲状态监测定时任务。

具体启动代码如下：

为了尽可能的提示性能，Netty在很多地方进行了无锁化的设计，例如在IO线程内部进行，线程操作，避免多线程竞争导致的性能下降问题。表面上看，串行化设计似乎CPU利用率不高，并发度不够。但是通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行设计相比一个队列---多个工作线程的模型更优。设计原理如下图:

Netty的NioEventLoop读取到消息之后，直接调用ChannelPipeLine的fireChannelRead(Object msg).只要用户不主动切换线程，一直都是由NioEventLoop调用用户的Handler，期间不进行线程切换。这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优的。

Netty的多线程编程最佳实践如下：

1),创建两个NioEventLoopGroup，用于隔离NIO Acceptor和NIO IO线程。

2),尽量不要在ChannelHandler中启动用户线程(解码后用于将POJO消息派发到后端业务线程的除外)。

3),解码要放在NIO线程调用的解码Handler中进行，不要切换到用户线程中完成消息的解码。

4),如果业务逻辑操作非常简单，没有复杂的业务逻辑计算，没有可能会导致线程被阻塞的磁盘操作，数据库操作，网络操作等，可以直接在NIO线程上完成业务逻辑编排，不需要切换到用户线程。

5),如果业务逻辑处理复杂，不要在NIO线程上，完成，建议将解码后的POJO消息封装成Task，派发到业务线程池中由业务线程执行，以保证NIO线程尽快被释放，处理其他的IO操作。

推荐的线程数量计算公式有以下两种。

1),公式1:线程数量=(线程总时间/瓶颈资源时间)*瓶颈资源线程的并行数；

2),公式2:QPS=1000/线程总时间*线程数。

由于用户场景的不同，对于一些复杂的系统，实际上很难计算出最优线程配置，只能是根据测试数据和用户场景，结合公式给出一个相对合理的范围，然后对范围内的数据进行性能测试，选择相对最优值。

注：本文主要参考netty权威指南。

vlambda博客
学习文章列表