当前位置：首页 > news >正文

I/O模型

news 2025/7/22 5:41:13

写在前面

前面聊完了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端要点

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

三、线程池+同步阻塞IO

在这里插入图片描述

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

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

四、reactor模式

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