ET模式与非阻塞IO的深度解析与实践指南

1. 为什么ET模式必须搭配非阻塞IO？

在Linux网络编程中，epoll的边沿触发模式（Edge Triggered，简称ET）以其高效著称，但有个铁律必须遵守：ET模式必须搭配非阻塞IO使用。这个看似简单的规则背后，隐藏着操作系统内核和网络编程模型的深刻原理。

1.1 ET模式的工作机制

ET模式是epoll的两种触发方式之一（另一种是水平触发LT）。它的核心特点是：仅在文件描述符状态变化时触发事件。比如：

• 当socket从不可读变为可读时（新数据到达）
• 当socket从不可写变为可写时（发送缓冲区有空闲）

这种设计带来了显著的性能优势：避免了重复通知，减少了系统调用次数。但同时也引入了一个关键问题：如果应用程序没有一次性处理完所有可用数据，后续不会再收到通知。

关键区别：LT模式会持续通知直到条件不满足，而ET模式只在状态变化时通知一次。

1.2 阻塞IO的致命缺陷

假设我们在ET模式下使用阻塞IO读取数据：

c复制int n = read(fd, buf, sizeof(buf));

当read()读取的数据量小于缓冲区大小时，可能有两种情况：

1. 数据已经全部读完（返回0表示对端关闭）
2. 还有数据未读完（内核缓冲区仍有数据）

如果是情况2，由于ET模式不会再次通知，剩下的数据就会"卡"在内核缓冲区，直到下次有新的数据到达才会触发事件。这直接导致了：

• 数据延迟处理
• 严重时可能造成请求堆积
• 完全违背了ET模式的设计初衷

1.3 非阻塞IO的救赎

非阻塞IO通过fcntl设置O_NONBLOCK标志实现：

c复制int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

这样read()在没数据时会立即返回-1并设置errno为EAGAIN/EWOULDBLOCK，而不是阻塞。结合ET模式，标准做法是：

c复制while ((n = read(fd, buf, sizeof(buf))) > 0) {
    // 处理数据
}
if (n == -1 && errno != EAGAIN) {
    // 真实错误处理
}

这种"读到空"的方式确保了：

1. 一次性取出所有可用数据
2. 不会因遗漏数据导致"饥饿"
3. 充分发挥ET模式的性能优势

2. ET模式的正确使用姿势

2.1 完整的事件处理流程

一个健壮的ET模式服务端通常包含以下步骤：

1. 创建epoll实例
2. 设置socket为非阻塞
3. 添加监听socket到epoll（EPOLLIN | EPOLLET）
4. 事件循环：
   • accept新连接（非阻塞）
   • 为新连接设置非阻塞并添加到epoll
   • 处理读写事件（必须循环读写直到EAGAIN）

c复制// 典型的事件处理代码片段
struct epoll_event ev;
while (1) {
    int nfds = epoll_wait(epfd, events, MAX_EVENTS, -1);
    for (int i = 0; i < nfds; i++) {
        if (events[i].data.fd == listen_fd) {
            // 处理新连接
            while ((conn_fd = accept(listen_fd, ...)) != -1) {
                set_nonblocking(conn_fd);
                ev.events = EPOLLIN | EPOLLET;
                epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);
            }
            if (errno != EAGAIN && errno != EWOULDBLOCK) {
                // 错误处理
            }
        } else {
            // 处理已连接socket
            if (events[i].events & EPOLLIN) {
                while ((n = read(events[i].data.fd, buf, BUF_SIZE)) > 0) {
                    // 处理数据
                }
                if (n == 0) {
                    // 对端关闭连接
                    close(events[i].data.fd);
                } else if (n == -1 && errno != EAGAIN) {
                    // 错误处理
                }
            }
            // 类似处理EPOLLOUT
        }
    }
}

2.2 必须注意的细节

1. accept的特殊性：

   • 即使使用ET模式，多个连接到达时可能只触发一次事件
   • 必须循环accept直到返回EAGAIN
   • 否则会留下未处理的连接请求

2. 读写分离：

   • 读事件和写事件最好分开处理
   • 避免在同一个回调中处理两种事件
   • 可以使用状态机管理连接状态

3. 错误处理：

   • EAGAIN/EWOULDBLOCK不是真正的错误
   • 需要特别处理ECONNRESET等网络错误
   • 错误时应及时关闭socket并移除epoll监控

3. 性能对比与实测数据

3.1 ET vs LT的性能差异

我们通过一个简单的echo服务器测试不同模式的表现（单核2.5GHz CPU，1000并发连接）：

关键发现：

• ET模式吞吐量提升2倍以上
• CPU占用显著降低
• 内存使用更高效

3.2 阻塞与非阻塞的对比

同样的ET模式下对比IO方式：

阻塞IO导致的性能劣化主要来自：

1. 未及时处理的数据堆积
2. 线程/进程可能被无意义阻塞
3. 无法充分利用ET的事件聚合优势

4. 常见陷阱与解决方案

4.1