Java面试10-网络IO模型详解

前言

Java面试专栏的第10篇，这篇博客 南国带你主要回顾一下在Java网络IO常见的几种模型 以及大名鼎鼎的Netty框架。

注意这里所讲的网络IO和我在Java面试09——IO知识大盘点 讲述的IO不一样，上一篇我们主要讲述的是文件的读写。传统IO的Java编程主要是以流的形式，NIO是以块的方式。当然 这一篇博客里面 我们还会讲述NIO。

该篇博客部分内容 参考以下博客，感谢前人的成果：
1.Java面试常考的 BIO，NIO，AIO 总结
2.面试|JAVA的网络IO模型彻底讲解

闲话不多说，干货送上~

1. 基本概念

java的I/O依赖于操作系统的实现，首先了解UNIX的I/O模型，首先我们先来弄清楚几个基本概念：同步与异步 阻塞与非阻塞。熟悉Java的朋友是不是看到之后 很熟悉了。如果 你之前 已经搞清楚这其中的区别，那么 就再次和南国一起 把知识回顾一下吧。

1.1 同步与异步

同步和异步描述的用户线程与内核之间交互方式。

• 同步： 指用户线程发起I/O请求后需要等待或者轮询内核I/O操作完成后才能继续执行。
• 异步： 指用户线程发起I/O请求后仍继续执行，当内核I/O操作完成后会通知用户线程，或者调用用户线程注册的回调函数。

同步和异步的区别最大在于异步的话调用者不需要等待处理结果，被调用者会通过回调等机制来通知调用者其返回结果。

1.2 阻塞与非阻塞

阻塞和非阻塞描述的是用户线程调用内核I/O操作的方式。

• 阻塞： 指I/O操作需要彻底完成后才返回到用户空间。
• 非阻塞： 指I/O被调用后立即返回给用户一个状态值，无须等到I/O操作彻底完成。

一个I/O操作其实分成两个步骤：发起I/O请求和实际的I/O操作。
阻塞I/O和非阻塞I/O的区别在于第一步，即发起I/O请求是否会被阻塞；如果阻塞直到完成就是传统的阻塞I/O，反之就是非阻塞I/O。
同步I/O和异步I/O的区别就是第二步骤是否阻塞，如果实际的I/O读写阻塞请求进程，那就是同步I/O，反之就是异步I/O。

举个生活中简单的例子，你妈妈让你烧水，小时候你比较笨啊，在哪里傻等着水开（同步阻塞）。等你稍微再长大一点，你知道每次烧水的空隙可以去干点其他事，然后只需要时不时来看看水开了没有（同步非阻塞）。后来，你们家用上了水开了会发出声音的壶，这样你就只需要听到响声后就知道水开了，你需要去倒水了，在听到响声之前 这期间你可以随便干自己的事情（异步非阻塞）。

2. BIO(Blocking I/O)

同步阻塞I/O模式，数据的读取写入必须阻塞在一个线程内等待其完成。

2.1 传统BIO(同步阻塞IO)

BIO通信（一请求一应答1:1）模型图如下:

采用 BIO 通信模型 的服务端，通常由一个独立的 Acceptor 线程负责监听客户端的连接。我们一般通过在 while(true) 循环中服务端会调用 accept() 方法等待接收客户端的连接的方式监听请求，请求一旦接收到一个连接请求，就可以建立通信套接字在这个通信套接字上进行读写操作，此时不能再接收其他客户端连接请求，只能等待同当前连接的客户端的操作执行完成， 不过可以通过多线程来支持多个客户端的连接，如上图所示。

如果要让 BIO 通信模型 能够同时处理多个客户端请求，就必须使用多线程（主要原因是 socket.accept()、 socket.read()、 socket.write() 涉及的三个主要函数都是同步阻塞的），也就是说它在接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的 一请求一应答通信模型 。

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

我们可以设想一下如果这个连接不做任何事情的话就会造成不必要的线程开销，不过可以通过 线程池机制 改善，线程池还可以让线程的创建和回收成本相对较低。使用 FixedThreadPool 可以有效的控制了线程的最大数量，保证了系统有限的资源的控制，实现了N(客户端请求数量):M(处理客户端请求的线程数量)的伪异步I/O模型（N 可以远远大于 M），下面一节"伪异步 BIO"中会详细介绍到。

2.2 伪异步 IO

后端通过一个线程池来处理多个客户端的请求接入，形成客户端个数M：线程池最大线程数N的比例关系，其中M可以远远大于N.通过线程池可以灵活地调配线程资源，设置线程的最大值，防止由于海量并发接入导致线程耗尽。

伪异步IO模型图(M:N)

采用线程池和任务队列可以实现一种叫做伪异步的 I/O 通信框架，它的模型图如上图所示。当有新的客户端接入时，将客户端的 Socket 封装成一个Task（该任务实现java.lang.Runnable接口）投递到后端的线程池中进行处理，JDK 的线程池维护一个消息队列和 N 个活跃线程，对消息队列中的任务进行处理。由于线程池可以设置消息队列的大小和最大线程数，因此，它的资源占用是可控的，无论多少个客户端并发访问，都不会导致资源的耗尽和宕机。

伪异步I/O通信框架采用了线程池实现，因此避免了为每个请求都创建一个独立线程造成的线程资源耗尽问题。不过因为它的底层还是同步阻塞的BIO模型，因此无法从根本上解决问题。

3. NIO

3.1 同步非阻塞IO

关于 NIO，南国在上一篇博客Java面试09——IO知识大盘点 中有描述过，NIO中的N可以理解为Non-blocking，不单纯是New。它提供了 Channel , Selector，Buffer3个核心组件，支持面向缓冲的，基于通道的I/O操作方法。 NIO提供了与传统BIO模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可靠性都不好；非阻塞模式正好与之相反。对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和更好的维护性；对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发。

但是在实际应用中，为什么大家都不愿意用 JDK 原生 NIO 进行开发呢？除了编程复杂、编程模型难之外，它还有以下让人诟病的问题：

• JDK 的 NIO 底层由 epoll 实现，该实现饱受诟病的空轮询 bug 会导致 cpu 飙升 100%
• 项目庞大之后，自行实现的 NIO 很容易出现各类 bug，维护成本较高，上面这一坨代码我都不能保证没有 bug

Netty 的出现很大程度上改善了 JDK 原生 NIO 所存在的一些让人难以忍受的问题。后续我们 会详细剖析Netty框架

3.2 异步非阻塞IO(AIO)

AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。

AIO 是异步IO的缩写，虽然 NIO 在网络操作中，提供了非阻塞的方法，但是 NIO 的 IO 行为还是同步的。对于 NIO 来说，我们的业务线程是在 IO 操作准备好时，得到通知，接着就由这个线程自行进行 IO 操作，IO操作本身是同步的。

说到这里 让我们来总结一下：

4. Netty

4.1 原理

Netty是一个高性能、异步事件驱动的NIO框架，基于JAVA NIO提供的API实现。它提供了对TCP、UDP和文件传输的支持，作为一个异步NIO框架，Netty的所有IO操作都是异步非阻塞的，通过Future-Listener机制，用户可以方便的主动获取或者通过通知机制获得IO操作结果。

4.2 高性能

在IO编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者IO多路复用技术进行处理。

IO多路复用技术通过把多个IO的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。

与Socket类和ServerSocket类相对应，NIO也提供了SocketChannel和ServerSocketChannel两种不同的套接字通道实现。

4.2.1 多路复用通讯方式

Netty架构按照Reactor模式设计和实现(Reactor模式 后面南国会讲到)。

服务端通信序列图如下：

备注：上图中部分文字没有显示出来。图中 7.设置新建客户端连接的Socket参数； 10.decode请求消息

客户端通信序列图如下：

备注：上图中部分文字没有显示出来。图中 9.判断连接是否完成，完成连接执行步骤10 12.decode请求消息

Netty的IO线程NioEventLoop由于聚合了多路复用器Selector，可以同时并发处理成百上千个客户端Channel，由于读写操作都是非阻塞的，这就可以充分提升IO线程的运行效率，避免由于频繁IO阻塞导致的线程挂起。

4.2.2 Reactor线程模型

常用的Reactor线程模型有三种：

• Reactor单线程模型；
• Reactor多线程模型；
• 主从Reactor多线程模型。

1.Reactor单线程模型
Reactor单线程模型，指的是所有的IO操作都在同一个NIO线程上面完成，NIO线程的职责如下： 1) 作为NIO服务端，接收客户端的TCP连接； 2) 作为NIO客户端，向服务端发起TCP连接； 3) 读取通信对端的请求或者应答消息； 4) 向通信对端发送消息请求或者应答消息。

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

这种方式不适合高负载，大并发的应用场景，主要原因如下:
A),一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便NIO线程的CPU负荷达到100%，也无法满足海量消息的编码、解码、读取和发送。
B),当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端链接超时，超时之后往往会进行重发，这更加重了NIO线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈。
C),可靠性问题:一旦NIO线程意外跑飞，或者进入死循环，会导致整个系统通讯模块不可用，不能接受和处理外部消息，造成节点故障。

2.Reactor多线程模型
Rector多线程模型与单线程模型最大的区别就是有一组NIO线程处理IO操作。 有专门一个NIO线程-Acceptor线程用于监听服务端，接收客户端的TCP连接请求； 网络IO操作-读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送；

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

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

3.主从Reactor多线程模型
服务端用于接收客户端连接的不再是个1个单独的NIO线程，而是一个独立的NIO线程池。Acceptor接收到客户端TCP连接请求处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到IO线程池（sub reactor线程池）的某个IO线程上，由它负责SocketChannel的读写和编解码工作。Acceptor线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作。

4.2.3 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/线程总时间线程数。

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