I/O模型

系列文章目录

1. Netty网络应用基础
2. Java I/O
3. IO/模型
4. 网络应用编解码
5. Netty Pipeline
6. Netty EventLoopGroup&EventLoop
7. Netty ThreadLocal&FastThreadLocal
8. Netty Future&Promise
9. Netty内存管理–(旧)PoolChunk&伙伴分配
10. Netty内存管理–内存池空间规格化SizeClasses
11. Netty内存管理–PoolChunk&PoolSubPage
12. Netty内存管理–内存池PoolArena
13. Netty内存管理–内存分配器PooledByteBufAllocator
14. Netty ObjectPool

---

写在前面

前面聊完了IO方式, 也就意味着网络数据的收发通道是建立起来了。但业务场景中, 通道本身是不会发送数据的。在常见的网络应用中, server端会创建多个链接以服务更多client, 同时要求各个client尽可能互不影响。这是I/O模型(也就是IO方式+线程模型)要解决的问题。由于加入了线程要素, 接下来首先聊几个流行语。

---

一、常见词汇

1. 同步/异步

同步/异步是应用和内核之间的协作模式。由于Linux Kernel托管了对所有外设的I/O, 因此对外设的I/O操作都需要通过系统调用完成。一般来说, 应用发起I/O请求, 内核负责I/O响应。所以更严谨来说, I/O请求和I/O响应的协作。在应用发起I/O操作之后, 如果内核立刻开始处理, 这就是同步协作; 如果应用发起I/O之后, 内核并不马上开始处理, 那么就是异步协作。

2. 阻塞/非阻塞

阻塞/非阻塞则强调应用线程发起I/O操作后的状态。为什么应用线程状态? 因为应用开发者需要知道, 操作对当前线程状态的影响。类似地, 不强调内核状态是因为站在软件分层的角度应用不应该关心Kernel。此外, 虽然线程状态与前面所说的协作模式有关, 但是两者描述的对象不同。这个在面试中很容易掉坑, 比如讲讲同步和阻塞的区别。

3. 举个栗子

比如你(应用)用打印机(内核)打印文件

IO方式	实例	评价
同步阻塞IO	你发起请求然后打印机立刻开始工作, 你站在打印机旁边等着啥也不干	你投入发请求, 处理请求和接响应的时间
同步非阻塞IO	你发起请求然后打印机立刻开始工作, 你继续忙手上的事情, 过了10分钟去拿结果	你投入发请求, 检查进度和接响应的时间
异步阻塞IO	你发起请求, 打印机就提示你文件已加入打印队列, 但是你就这么看着, 直到打印机把自己的文件打好	你投入发请求, 处理请求(老板知道直挠头)和接响应的时间
异步非阻塞IO	你发起请求, 打印机提示你10分钟去拿结果	你投入发请求和接响应的时间

二、server端要点

1. 服务于多用户(天南海北都能连接), 因此需要创建多个链接;
2. 由于链接的独立性, 每个链接支持独立读写(各个链接的数据不会串门);
3. 每个链接是自己创建的, 在数据确定的情况下直接写入即可, 因此独立写入比较明确;
4. 链接一有数据尽快读取。这点比较困难,因为读取的数据来自client, client何时写是不确定的, server端需要有一种感知机制;

三、线程池+同步阻塞IO

1. 一般由一个线程负责accept新的connection, 而后给每个connection在server端对应一个处理的Thread;
2. 由于connection会断开, 而Thread创建成本较高, 因此可以使用ThreadPool来管理;
3. 数据接收通过SocketInputStream完成; 没有数据时, 线程处于block状态;
4. 数据发送通过SocketOutputStream完成;
5. 连接数受线程数限制, 因此支持的链接数非常有限。但由于实现简单, 如果并发连接数可控比如20个上限也可以考虑(比如一些技术验证); 此外, 如果发送的消息比较大(M级别), 由于存在多次复制, 数据发送延迟也会比较明显。

到这里, 想必你已意识到网络应用中server端的三大块–连接管理, IO管理和应用逻辑。而IO管理和应用逻辑对资源的消耗与连接数呈正相关。一请求一线程模式, 随着链接数的上升CPU占用直线上升, 这就是著名的C10K问题。业界认为过多的线程切换, 数据的多次复制均需要CPU参与最终导致了这一结果。于是就有了下面的改进方案。

四、同步非阻塞IO(多路复用IO、reactor模式)

1. 数据读取开始前, 先由一个线程(称为reactor)获取链接的ready标记;
2. 仅对存在数据的链接读取数据, 数据读取完成后作为一个事件放入一个事件队列(称为EventQueue)中;
3. 创建一个处理线程(EventLoop)循环读取事件队列中的而后处理;
4. 数据写入时也放入队列中, 由处理线程读取并发送;
5. 相比于一请求一线程模式, reactor模式可以使用更少的线程, 节约了CPU的调度时间。此外, IO方式需要增加对ready标记读取支持, 这就是同步非阻塞IO。试想如果数据已经ready, 则意味着内核已经完成数据读取, 只是等待应用发起拷贝而已。因此, 实际的读取过程依然是内存复制完成, 用户线程依然是阻塞的。
6. Netty对此做了优化, 做到应用内存与内核共享部分堆外内存, 减少了内核到应用的一次拷贝, 进一步提升性能。以下是reactor模式的几种实现, 本质上是对Reactor线程和EventLoop线程的组合。

1. 单reactor+单 EventLoop

2. 单reactor+N EventLoop

3. (单reactor+N EventLoop) * N

五、Proactor模式

从前面的内容中, 我们知道在数据读取中的一个问题是, 如何知道有数据需要读取。除了应用层可以通过线程主动轮训外, 也可以由Kernel来通知我们。这样, 应用仅需要注册必要的处理函数, Kernel接收到数据后触发对应的函数即可。毕竟, 通知最开始也是Kernel知道的。这就是异步IO, 基于该IO的是大名鼎鼎的Proactor模式。

1. 数据读取

整个读取过程分为3个独立子过程, 注册处理函数，内核准备数据，内核触发函数。其中数据读取支持Kernel与应用共享内存以减少拷贝，内核准备完成后充当reactor线程直接触发应用侧注册的函数。

2. 数据写入

数据写入过程与读取过程类似，此处不再赘述。

3. 小结

1. 从应用侧来看，职责非常简单，仅做最少需要的逻辑处理即可。但反过来，这种IO方式对内核提出了更高的要求，更多的职责由内核完成。但是内核是庞大而复杂的，需要考虑的场景也更加复杂，因此更新过程必然是严谨，慎重而缓慢的。应用与之耦合遇到问题就会令人头疼。
2. 相比于Reactor，扩展性上应该有一定提升，但具体实现对Kernel依赖比较重。 Linux平台下AIO是基于支持NIO的函数模拟实现, 因此扩展性的提升相对有限。但现有的NIO实现已经存在多年, 相对稳定且满足了大部分需要, 因此AIO并没有被广泛应用。
3. 大神Robert Graham曾经在这里讲过，内核本身就是限制扩展性的根源。他的建议是尽可能让内核少做事情。因此可以想见, AIO的推广应用比较渺茫。这也是Netty框架至今仍然使用NIO的原因。

总结

以上就是今天要讲的内容，本文介绍了Java网络应用中的几种IO模型，希望能于在读的你能更好理解IO模型，于我个人能做进一步的整理和总结。