夢の終着駅

（一）工作机制#

当客户端向服务器发起连接时，服务端会为每个连接创建独立的线程，由该线程全权处理该连接的所有读写操作：

• 同步：线程需主动发起 I/O 请求，并在操作完成前持续等待。
• 阻塞：若数据未就绪，线程会被挂起，无法执行其他任务。

也就是说，连接服务端和客户端的线程无论是否接受到IO请求，都会一直占用线程空间。

（二）优缺点#

• 优点：编程简单，逻辑直观，维护成本低。
• 缺点：
  • 线程数随连接数线性增长，高并发时资源消耗巨大。
  • 线程阻塞导致 CPU 利用率低。

（三）适用场景#

• 连接数少且固定。
• 低并发场景。

（四）改良#

由此可见，改良方案无法解决 BIO 内核级阻塞的根本缺陷，因此催生了更高效的 NIO 模型。

（一）工作机制#

可以看到服务端和客户端之间其实是没有建立起永久线程连接的，所有线程都是复用选择器线程来实现的，要了解具体的工作机制是什么样之前，我们需要了解NIO的三个核心组件：

• Channel（通道）

        这是一个双向通信管道，是负责将搬运缓冲区的数据的渠道，本身并不存储数据。

        有同学可能会搞混通道和线程的概念，可以参考以下表格：

        可以打个通俗的比方，通道是火车，只负责把货物运输到目的地，而线程是工人，是负责处理这一批货物的。

        一个工人可以处理多批火车的货物，同样一个线程可以处理成千上万个管道的数据。

• Buffer（缓冲区）

        这是一个数据存储的容器，可以临时存储写入的数据，一端如果要发送数据到另一端，只需要将数据写入对应的缓冲区，然后给选择器发送一个写事件即可。如果另一端要读取数据的话也只需要给选择器发送一个读事件，然后从缓冲池中获取对应的缓冲区即可。

        与BIO通过字节流依赖于内核缓冲区不同，NIO将内核缓冲区和用户缓冲区分开。

• Selector（选择器）

        这是一个事件监听器，工作线程会轮询每个端口检查是否有对应的事件，一旦检测到有事件，就会判断事件类型并执行对应的逻辑，比如说选择器检测到客户端的读事件后，工作线程会建立起客户端与服务端的连接，然后读取缓冲区的数据并执行代码逻辑，执行完后则继续检查下一个端口。

在了解完以上组件概念后，我们来分析一下NIO的工作机制：

A想要向B传输数据，那A先把要传输的数据写到缓冲区中，并发送一个写事件，此时工作线程轮询到A端口时选择器发现存在事件，因此建立其与对应客户端的连接，然后客户端准备就绪后会发起一个读事件，工作线程确认之后就会将缓冲区的数据从用户缓冲区拷贝到内核缓冲区中，由此完成了一次数据传输。

（二）优缺点#

• 优点：
  • 单线程管理大量连接，减少线程切换开销。
  • 非阻塞机制提高 CPU 利用率。
• 缺点：编程复杂，需处理缓冲区、事件状态等细节。

（三）适用场景#

• 高并发短连接。
• 连接数多但活跃度不高的系统。

为何连接数多且活跃度高的场景不适用NIO？因为NIO依旧是同步机制，是确保数据从用户区传输到内核区之后才算完成，在传输过程中仍有阻塞时间，如果活跃度高的话可能会导致缓冲区的数据溢出，即使没有溢出，其量级也不可小觑，会大大加长传输时间，然后连接数再一加多的话，此时NIO的性能就会很慢了。

因此在此基础上，需要更彻底的异步模型——AIO。

（一）工作机制#

AIO 的核心原理是操作系统级异步支持，与 NIO 的多路复用有本质区别。

• 异步流程：
  • 应用程序发起 I/O 请求后立即返回，无需阻塞等待 。
  • 数据由操作系统内核直接处理。
• 回调通知：
  • I/O 操作完成后，内核通过信号或回调函数主动通知应用程序处理结果。

如果A要向B传输数据，A会将数据写入用户缓冲区，然后调用内核IO，让其接管并将数据写入内核区，再通过回调通知监控线程做后续逻辑处理，这样就实现了异步机制。

（二）优缺点#

• 优点：
  • 零阻塞，线程资源利用率极高。
  • 回调机制简化高并发编程。
• 缺点：
  • 编程模型复杂（回调嵌套易导致“回调地狱”）。
  • 依赖操作系统支持（Linux 支持较弱，Windows 通过 IOCP 实现较好）。

（三）适用场景#

• 高并发长连接。
• I/O 操作耗时长且需高吞吐的场景。