介绍一下 Reactor 线程模型？

Reactor 线程模型面试回答

【核心定义】

Reactor 线程模型是一种基于事件驱动和 I/O 多路复用的高性能网络编程模型，通过单线程或有限线程处理大量并发连接，实现高吞吐和低延迟。

【关键要点】

事件驱动架构：将 I/O 操作抽象为事件，通过事件循环（Event Loop）统一调度，避免为每个连接创建独立线程
多路复用技术：使用 select/poll/epoll/kqueue 等系统调用，单线程可监听成千上万个 socket 状态变化
职责分离设计：通常分为 Acceptor（接收连接）、Dispatcher（事件分发）、Handler（事件处理）三个核心角色
线程模型变体：根据业务场景演化出单 Reactor 单线程、单 Reactor 多线程、主从 Reactor 多线程等模式

【深度推导/细节】

核心矛盾解决逻辑

问题：传统 BIO 模型中“一线程一连接”导致线程资源耗尽，C10K 问题无法解决

Reactor 解决方案拆解：

Step 1: 注册监听
    - 将所有 socket（监听socket + 连接socket）注册到多路复用器
    - 设置关注事件：ACCEPT（新连接）、READ（数据到达）、WRITE（可写）

Step 2: 事件循环
    while (true) {
        // 阻塞等待事件发生（内核级高效）
        events = selector.select(timeout);

        // 遍历就绪事件
        for (Event event : events) {
            if (event.isAcceptable()) {
                // 新连接处理
                acceptConnection();
            } else if (event.isReadable()) {
                // 数据读取
                readAndProcess();
            } else if (event.isWritable()) {
                // 数据写入
                writeData();
            }
        }
    }

Step 3: 异步处理
    - 对于耗时业务逻辑，提交到线程池异步执行
    - 避免阻塞事件循环线程

三种经典线程模型对比

1. 单 Reactor 单线程

架构：一个线程完成所有工作
流程：Acceptor + Handler 都在 EventLoop 线程
适用：Redis（纯内存操作）、简单业务场景
瓶颈：Handler 耗时操作会阻塞整个系统

2. 单 Reactor 多线程

架构：一个 Reactor 线程 + 业务线程池
流程：
    - Reactor 线程：监听 + 解码/编码 + 分发
    - 线程池：执行业务逻辑
优点：业务处理不阻塞 I/O
缺点：Reactor 单点压力大，编解码可能成为瓶颈

3. 主从 Reactor 多线程（Netty 默认模式）

架构：
    - Main Reactor：1个，负责 Accept 新连接
    - Sub Reactor：N个，负责已建立连接的 I/O 读写
    - 业务线程池：M个，负责业务处理

流程分解：
    Step 1: Main Reactor 监听 ServerSocketChannel
    Step 2: 新连接到达 → 注册到 Sub Reactor（负载均衡）
    Step 3: Sub Reactor 处理该连接的所有 I/O 事件
    Step 4: 耗时业务 → 提交到业务线程池

设计合理性：
    - Main Reactor 专用：保证新连接快速响应
    - Sub Reactor 分组：连接隔离，避免单个 Reactor 过载
    - 线程池分离：I/O 线程专注网络，业务线程专注逻辑

【关联/对比】

Reactor vs Proactor

维度	Reactor	Proactor
通知时机	就绪时通知（可读/可写）	完成时通知（已读/已写）
操作主体	应用程序执行 I/O	操作系统执行 I/O
编程复杂度	相对简单	回调地狱风险
典型实现	Linux epoll	Windows IOCP

Reactor vs 传统 BIO

线程资源：BIO 1:1 连接 vs Reactor 1:N 连接（N 可达数万）
上下文切换：BIO 频繁切换 vs Reactor 极少切换
内存消耗：BIO 每个线程 1MB+ 栈 vs Reactor 共享线程
延迟表现：BIO 连接建立快 vs Reactor 事件响应快

实际应用关联

Netty：主从 Reactor + 无锁化设计
Redis：单 Reactor + 纯内存操作
Nginx：多进程 + Reactor（每个 worker 一个事件循环）
Tomcat NIO：Poller（Reactor） + Executor（线程池）

『面试官追问』

高频问题 1：为什么选择 0.75 作为负载因子？

技术事实：这不是 Reactor 特有的，但类似设计思想

空间时间权衡：0.75 是数学推导的较优值（泊松分布）
扩容触发点：元素数量达到容量 75% 时扩容，避免过早/过晚
哈希冲突控制：保证链表长度超过 8 的概率小于千万分之一

高频问题 2：Reactor 如何处理惊群效应？

解决方案：

SO_REUSEPORT（Linux 3.9+）：内核级负载均衡，多个进程绑定同一端口
Accept 锁：Nginx 方案，进程间竞争锁，只有持有锁的进程 accept
EPOLLEXCLUSIVE（Linux 4.5+）：避免多个线程同时被唤醒

高频问题 3：Reactor 线程数设置多少合适？

计算公式：

I/O 密集型：CPU 核数 * (1 + 平均等待时间/平均计算时间)
一般场景：CPU 核数 * 2（超线程考虑）
Netty 推荐：Sub Reactor 数 = CPU 核数 * 2

高频问题 4：如何保证线程安全？

无锁化设计策略：

线程绑定：一个 Channel 生命周期内只由一个 EventLoop 处理
任务队列：跨线程提交任务通过 MPSC（多生产者单消费者）队列
内存屏障：volatile + CAS 保证状态可见性
写时复制：配置变更时创建新对象，避免锁竞争

高频问题 5：Reactor 模式缺点？

局限性分析：

编程复杂度：回调地狱（Callback Hell），需配合 Promise/Future
调试困难：异步调用栈不连续
CPU 密集型不适：耗时计算会阻塞事件循环
缓冲区管理：需要精细控制 ByteBuffer 生命周期

【版本差异/演进】

Java NIO 演进

JDK 1.4：引入 NIO，提供 Selector 基础支持
JDK 1.7：NIO.2（AIO），支持异步文件操作
JDK 11：优化 Selector 实现，减少系统调用

Netty 版本优化

Netty 3 → Netty 4：ChannelPipeline 线程模型重构
Netty 4.0 → 4.1：内存池化、FastThreadLocal 优化
Netty 4.1：默认使用 EPOLL ET 模式，减少事件触发次数

操作系统支持

Linux 2.6：epoll 成熟，成为 Reactor 首选
Linux 4.5+：EPOLLEXCLUSIVE 解决惊群
Windows：IOCP（Proactor）为主，Netty 通过 JNI 封装

总结要点：Reactor 的核心价值在于用有限线程处理海量连接，通过事件驱动和职责分离实现高并发。选择具体模型时需权衡业务特性：简单场景用单线程，I/O 密集型用主从模型，CPU 密集型需结合线程池。现代框架（如 Netty）通过无锁化和内存池进一步优化，使 Reactor 成为百万级并发的事实标准。

# 介绍一下 Reactor 线程模型？