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

一、引言：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：调用 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 的系统层面差异

七、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 调度，自动复用。

八、性能与资源分析

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

九、演进史：从 C10K 到 C1000K

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();

十二、典型误区与反例

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

未来方向：

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

十四、思考与练习

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

十五、小结

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

在现代服务端编程中：

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

• Game Server
• Game
• Game in Action
• Programming