事件循环

一、事件循环的本质：从快递分拣中心说起

1.1 现实世界类比

假设你经营一家快递分拣中心：
- **传统阻塞模型**（多线程）：
  每个包裹（请求）分配一个工人（线程）
  工人必须全程跟踪包裹：接收 → 分拣 → 装车
  即使工人90%时间在等待货车，也不能处理其他包裹

- **事件循环模型**：
  少数高效工人（事件循环线程）
  每个工人管理多个传送带（Socket通道）
  工人只处理就绪的包裹（就绪的I/O事件）

1.2 传统模型的瓶颈

事件循环（Event Loop）： 一种程序结构，通过无限循环持续监听并分发I/O事件，其核心组件包括：

事件队列：存储待处理事件（新连接、数据到达等）
事件分发器：检测哪些通道（Channel）已就绪
事件处理器：处理具体I/O操作的回调函数

二、多路复用技术：事件循环的"火眼金睛"

2.1 从BIO到NIO的演进

模型	工作方式	资源消耗	适用场景
BIO	1线程1连接（阻塞等待）	随连接数线性增长	低并发场景
select	遍历所有fd检查状态	O(n)时间复杂度	少量连接
epoll	回调通知就绪事件	O(1)时间复杂度	万级连接

2.2 epoll的三大核心能力

2.2.1 红黑树管理文件描述符集

// 创建epoll实例
int epoll_fd = epoll_create1(0);

// 添加监控描述符
struct epoll_event event;
event.events = EPOLLIN | EPOLLET; // 边缘触发模式
event.data.fd = socket_fd;
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, socket_fd, &event);

2.2.1 就绪列表与事件回调

// 等待事件发生（毫秒级超时）
int num_events = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);

// 处理就绪事件
for (int i = 0; i < num_events; i++) {
    if (events[i].events & EPOLLIN) {
        handle_read(events[i].data.fd);
    }
}

2.2.3 触发模式选择

水平触发（LT）：只要缓冲区有数据就会持续通知
边缘触发（ET）：仅在状态变化时通知一次（性能更优）

三、Netty的事件循环实现

3.1 核心组件关系图

┌───────────────────────────┐
│        EventLoopGroup     │
│  ┌─────────────────────┐  │
│  │   NioEventLoop[]    │  │
│  │ ┌─────────────────┐ │  │
│  │ │   Selector      │ │  │
│  │ │  (epoll实例)     │ │  │
│  │ └─────────────────┘ │  │
│  │ │  Task Queue     │ │  │
│  │ └─────────────────┘ │  │
│  └─────────────────────┘  │
└───────────────────────────┘

3.2 事件循环线程的生命周期

// 简化版事件循环伪代码
public void run() {
    while (!terminated) {
        // 阶段1：检测I/O事件
        int readyChannels = selector.select(timeout);
        
        // 阶段2：处理I/O事件
        if (readyChannels > 0) {
            Set<SelectionKey> keys = selector.selectedKeys();
            for (SelectionKey key : keys) {
                if (key.isReadable()) {
                    handleRead(key);
                }
                if (key.isWritable()) {
                    handleWrite(key);
                }
            }
            keys.clear();
        }
        
        // 阶段3：处理异步任务
        runAllTasks();
    }
}

3.3 关键性能优化手段

I/O比例控制：通过ioRatio参数平衡I/O与任务处理时间

// 默认配置：I/O操作占用50%时间
NioEventLoopGroup group = new NioEventLoopGroup(4, new DefaultThreadFactory(), 50);

直接内存分配：使用ByteBuf避免JVM堆内存拷贝
零拷贝技术：文件传输通过FileRegion直接操作内核缓冲区

四、性能对比：理论 vs 现实

4.1 理论计算模型

C10K问题公式推导： 传统模型所需线程数 = 并发连接数 × (平均等待时间 / 平均处理时间) 假设：

10,000并发连接
每个请求95%时间在等待（19ms等待 + 1ms处理）

传统模型线程数 = 10,000 × (19/1) = 190,000 → 完全不可行
事件循环模型线程数 = CPU核心数（如4线程）→ 轻松应对

五、从内核到应用：全链路视角看事件循环

5.1 Linux内核的工作流程

应用层（Java NIO）
  ↓ 系统调用（epoll_ctl/epoll_wait）
VFS（虚拟文件系统层）
  ↓ 回调注册
网卡驱动
  ↓ 硬件中断
DMA缓冲区 → 数据就绪 → 触发epoll回调

5.2 现代网络栈优化

RSS（接收端扩展）：多队列网卡分散中断压力
SO_REUSEPORT：允许多个Socket监听同一端口
Kernel Bypass：DPDK/XDK等用户态网络方案

六、最佳实践：如何最大化事件循环效率

6.1 配置原则

# 推荐Netty配置
server:
  netty:
    event-loop:
      boss-count: 1               # 接收连接线程数
      worker-count: cpu_cores * 2 # 处理I/O线程数
    max-initial-line-length: 8192
    so-backlog: 1024              # 等待连接队列大小

6.2 禁忌事项

❌ 在事件循环线程执行阻塞操作
❌ 忘记释放ByteBuf导致内存泄漏
❌ 在Handler中处理耗时业务逻辑

6.3 监控指标

关键Metric：
  reactor.netty.io.allocated.direct：直接内存使用量
  reactor.netty.io.pending.tasks：待处理任务数
  reactor.netty.io.select.latency：select操作延迟