game

《游戏服务端编程实践》2.1.1　阻塞与非阻塞 I/O

解析游戏服务器的阻塞与非阻塞 I/O 模型，包括其原理、优势与劣势。同时，介绍异步 I/O 模型，展示如何在不阻塞线程的情况下处理多个连接。

Leeting Yan 7 分钟阅读 3127 字

一、引言：I/O 模型是服务端的灵魂

在游戏服务器、即时通信系统或高并发 API 网关中，开发者最常听到的词之一就是“I/O 模型（Input/Output Model）”。
它看似底层，但决定了系统能否同时服务 10 个用户、10 万个用户，甚至 100 万个连接。

一个简单的例子：

当客户端向服务器发送消息时，操作系统必须完成三个动作：
① 读取数据包 → ② 处理请求 → ③ 返回结果。

如果每一个 I/O 都阻塞线程等待数据到达，那么一万连接就需要一万个线程；
如果我们能做到“不阻塞等待”，而是在数据可读时再被唤醒，那同样的 CPU 就能同时服务数十万连接。

I/O 模型之于服务器的意义，正如战术体系之于军队：

  • 同样的武器，不同的战法，战斗力差距数十倍。

二、基础概念：什么是 I/O？

2.1.1.1 内核中的 I/O 过程

在操作系统视角下，一次网络 I/O（以读取 socket 为例）包括两个阶段：

阶段描述
等待数据就绪内核从网卡接收数据包，复制到内核缓冲区；若数据未到，线程需等待。
数据拷贝到用户空间内核将数据从内核缓冲区复制到用户缓冲区（程序的内存中）。

所谓“阻塞”与“非阻塞”，本质区别就在于线程在等待阶段是否睡眠。

2.1.1.2 五种典型 I/O 模型（Unix 分类）

根据线程在这两个阶段的行为不同，经典 Unix I/O 模型分为五种：

模型阻塞等待？多路复用？适用场景
① 阻塞 I/O（Blocking I/O）✅ 是❌ 否早期系统，简单应用
② 非阻塞 I/O（Non-blocking I/O）❌ 否❌ 否低延迟轮询场景
③ I/O 多路复用（select/poll/epoll）❌ 否✅ 是高并发服务
④ 信号驱动 I/O（Signal-driven I/O）❌ 否✅ 是（信号）较少使用
⑤ 异步 I/O（Asynchronous I/O）❌ 否✅ 完全异步高性能 I/O 密集型服务

其中：

  • 阻塞 I/O：调用 read() 时，线程挂起等待；
  • 非阻塞 I/O：调用 read() 时立即返回 EWOULDBLOCK；
  • I/O 复用：用 epoll 等机制等待“哪个 fd 可读”，不阻塞单一连接；
  • 异步 I/O：内核完成整个读写并主动通知程序。

三、阻塞 I/O（Blocking I/O）

3.1 定义

在阻塞 I/O 模型中，当应用程序调用 read() 或 recvfrom() 时，如果数据未准备好，系统调用将一直阻塞，直到数据到达并被复制到用户空间为止。

3.2 时序示意

sequenceDiagram
    participant App as 应用程序
    participant Kernel as 内核
    App->>Kernel: read(socket)
    Note right of Kernel: 等待数据到达<br/>数据拷贝到内核缓冲区
    Kernel-->>App: 返回数据

3.3 特征

  • 调用线程被挂起；
  • 编程模型简单；
  • 一个连接一个线程；
  • 并发数受线程数量限制；
  • 上下文切换开销大。

3.4 示例：Java 阻塞 Socket

try (ServerSocket server = new ServerSocket(8080)) {
    while (true) {
        Socket client = server.accept();   // 阻塞等待连接
        new Thread(() -> handle(client)).start();
    }
}

在上面的代码中：

  • accept() 会阻塞直到有新连接；
  • 每个连接由独立线程处理；
  • 若有 1 万连接，就有 1 万线程。

这就是最经典的 C10K 问题（如何同时处理 1 万个连接）。

四、非阻塞 I/O（Non-blocking I/O）

4.1 定义

在非阻塞 I/O 模型中，应用程序调用 read() 时，如果数据未准备好，不会等待，而是立即返回一个错误码（EAGAIN 或 EWOULDBLOCK）。
应用程序需要不断轮询检查数据是否可读。

4.2 时序图

sequenceDiagram
    participant App
    participant Kernel
    App->>Kernel: read(socket)
    Kernel-->>App: EWOULDBLOCK
    loop 轮询
        App->>Kernel: read(socket)
    end
    Kernel-->>App: 返回数据

4.3 优点

  • 不会阻塞线程；
  • 可同时管理多个连接；
  • 实时性更高。

4.4 缺点

  • 消耗 CPU；
  • 需要主动轮询；
  • 代码复杂。

4.5 示例：Java NIO 非阻塞模式

SocketChannel channel = SocketChannel.open();
channel.configureBlocking(false);
ByteBuffer buf = ByteBuffer.allocate(1024);

while (true) {
    int n = channel.read(buf);
    if (n == 0) {
        Thread.yield();
        continue;
    } else if (n < 0) break;
    process(buf);
}

这种轮询模型几乎不会在真实生产环境中单独使用，而是作为 epoll、select 的底层实现。

五、I/O 多路复用（Multiplexing）

非阻塞 I/O 的轮询非常消耗 CPU，因此操作系统提供了一种在一个线程内等待多个文件描述符就绪的机制：

select、poll、epoll（Linux）或 kqueue（BSD/macOS）。

这就是后面将要详细讲解的 Reactor 模式 的基础。

5.1 核心思想

  • 注册所有连接；
  • 内核等待任意连接可读/可写；
  • 唤醒线程；
  • 由程序执行相应 I/O 操作。

5.2 关键调用示例（Linux）

int epoll_fd = epoll_create(1);
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, sockfd, &ev);
int n = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);

5.3 优点

  • 高并发下线程数极少；
  • CPU 利用率高；
  • 是现代服务器（如 Nginx、Netty、Skynet）的基础。

六、阻塞与非阻塞 I/O 的系统层面差异

对比维度阻塞 I/O非阻塞 I/O
系统调用行为阻塞当前线程立即返回
CPU 利用率低高（轮询）
实现复杂度简单复杂
延迟不稳定（阻塞）稳定（轮询）
典型应用小型服务高并发服务
与 Reactor 的关系无基础单元

七、Java NIO、Go netpoll 与操作系统的联系

7.1 Java NIO

  • 基于 Selector + Channel；
  • Selector 内部使用 epoll 或 kqueue；
  • 非阻塞模式下，read/write 不阻塞线程；
  • 底层由内核事件通知机制支持。
Selector selector = Selector.open();
ServerSocketChannel server = ServerSocketChannel.open();
server.bind(new InetSocketAddress(8080));
server.configureBlocking(false);
server.register(selector, SelectionKey.OP_ACCEPT);

7.2 Go 的 netpoll

Go 的 net 包内部实现了一个抽象的 poller，在不同操作系统上分别使用：

  • Linux：epoll；
  • macOS：kqueue；
  • Windows：IOCP。

并通过 goroutine + epoll_wait 实现 M:N 调度，自动复用。

八、性能与资源分析

维度阻塞 I/O非阻塞 + epoll
线程数N（连接数）固定（通常 CPU 数）
上下文切换高低
内存占用高低
可扩展性低高
平均延迟不稳定可控
编程复杂度简单中等
调试难度低高

这就是为什么现代服务器（如 Netty、Nginx、Go net/http）几乎都采用非阻塞多路复用。

九、演进史：从 C10K 到 C1000K

年代特征代表系统
1990s阻塞 I/O + 线程模型Apache 1.x
2000s非阻塞 + select/pollearly Nginx
2010sepoll + ReactorNetty、Node.js
2020s协程 + 异步 I/OGo、Rust Tokio、Java Loom

C10K 问题：

“如何用一台机器同时维持 10,000 个并发连接？”

其答案正是 非阻塞 I/O + 事件驱动架构。

十、阻塞与非阻塞 I/O 的实战体验

Java 阻塞 Echo Server

ServerSocket server = new ServerSocket(8080);
while (true) {
    Socket client = server.accept();
    new Thread(() -> {
        try (InputStream in = client.getInputStream();
             OutputStream out = client.getOutputStream()) {
            byte[] buf = new byte[1024];
            int n;
            while ((n = in.read(buf)) != -1) {
                out.write(buf, 0, n);
            }
        } catch (IOException e) {}
    }).start();
}
  • 简单直观；
  • 每连接一线程；
  • 可扩展性差。

Java NIO 非阻塞 Echo Server

Selector selector = Selector.open();
ServerSocketChannel server = ServerSocketChannel.open();
server.bind(new InetSocketAddress(8080));
server.configureBlocking(false);
server.register(selector, SelectionKey.OP_ACCEPT);

while (true) {
    selector.select();
    for (SelectionKey key : selector.selectedKeys()) {
        if (key.isAcceptable()) {
            SocketChannel client = server.accept();
            client.configureBlocking(false);
            client.register(selector, SelectionKey.OP_READ);
        } else if (key.isReadable()) {
            SocketChannel client = (SocketChannel) key.channel();
            ByteBuffer buf = ByteBuffer.allocate(1024);
            int n = client.read(buf);
            if (n == -1) client.close();
            buf.flip();
            client.write(buf);
        }
    }
}
  • 单线程管理多个连接；
  • 高并发；
  • I/O 延迟可控。

Go Echo Server（基于 netpoll）

package main
import (
    "bufio"
    "fmt"
    "net"
)

func main() {
    ln, _ := net.Listen("tcp", ":8080")
    for {
        conn, _ := ln.Accept()
        go func(c net.Conn) {
            defer c.Close()
            r := bufio.NewReader(c)
            for {
                line, err := r.ReadString('\n')
                if err != nil { return }
                fmt.Fprintf(c, "Echo: %s", line)
            }
        }(conn)
    }
}
  • 每连接一个 goroutine，但 goroutine 并非真实线程；
  • Go runtime 使用 epoll/kqueue 统一调度；
  • 等价于“用户态轻量协程 + 非阻塞 I/O”。

十一、阻塞与非阻塞的混合使用

在实际系统中，并不是所有 I/O 都必须非阻塞。
例如：

  • 数据库查询、磁盘 I/O 往往仍是阻塞的；
  • 网络层使用非阻塞；
  • 可以通过异步线程池隔离。

Java 示例（使用 Netty）：

EventLoopGroup boss = new NioEventLoopGroup(1);
EventLoopGroup worker = new NioEventLoopGroup();
ServerBootstrap b = new ServerBootstrap()
    .group(boss, worker)
    .channel(NioServerSocketChannel.class)
    .childHandler(new ChannelInitializer<>() {
        protected void initChannel(SocketChannel ch) {
            ch.pipeline().addLast(new EchoHandler());
        }
    });
b.bind(8080).sync();

十二、典型误区与反例

错误做法后果正确方式
每连接一线程内存爆炸使用 epoll/NIO
忘记设置非阻塞程序卡死调用 configureBlocking(false)
主线程执行耗时逻辑阻塞事件循环使用任务队列或线程池
忽略异常关闭文件描述符泄漏确保 finally 关闭

十三、现代趋势：异步 I/O 与协程模型

模型特点代表
Reactor（事件驱动）注册事件、回调执行Netty、Node.js
Proactor（异步完成通知）内核完成后通知Windows IOCP
协程用户态异步、代码同步化Go、Rust async、Java Loom

未来方向：

  • 以协程 + 异步 I/O 为核心；
  • 编写体验接近阻塞模型；
  • 实际运行是非阻塞异步。

十四、思考与练习

  1. 为什么阻塞 I/O 在低并发下反而性能更好？
  2. Go 的 goroutine 模型如何避免 C10K 问题？
  3. epoll 为什么能支持百万连接而不消耗 CPU？
  4. 请写出一个混合模型：主线程 epoll + 后台线程池处理任务。
  5. 如果你要实现一个实时聊天系统，你会选哪种 I/O 模型？为什么？

十五、小结

阻塞与非阻塞 I/O 的区别，不仅是“是否等待”，更是系统资源管理哲学的不同。

思想层面阻塞 I/O非阻塞 I/O
资源模型一连接一线程事件驱动复用
关注点任务执行事件调度
适合场景简单、小规模大规模、高并发
代表技术Apache、传统 SocketNetty、Nginx、Go、Rust Tokio

在现代服务端编程中：

  • 阻塞 I/O 仍有价值（简单易用、低延迟场景）；
  • 但非阻塞 I/O + 事件驱动模型已成为事实标准；
  • 它是 Reactor、Actor、协程调度的所有理论基础。

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页