2. 轮询机制详解：什么是轮询？从单片机到现代操作系统的进化

说实话，我第一次接触轮询是在大学做单片机课设的时候。那个小灯闪烁的实验，我写了整整一页的while(1)循环。当时觉得这就是编程的全部了——不断检查，然后执行。

后来工作了，优化一个服务端的CPU占用率，发现一个看似简单的read操作，背后居然卡死了整个核心。我才意识到，轮询这件事，远没有表面那么简单。

2.1 轮询的原始定义

轮询，英文叫Polling。说白了就是主动去问。CPU不断去检查某个状态位、某个寄存器、或者某个缓冲区，看看有没有新数据。如果没有，那就继续查。直到查到为止。

嗯，我们来看一个最典型的例子。单片机里检测按键按下：

void main() {
    while(1) {
        // 不断检查IO口电平
        if (GPIO_ReadPin(BUTTON_PIN) == 0) {
            delay_ms(20);  // 消抖
            if (GPIO_ReadPin(BUTTON_PIN) == 0) {
                // 执行按键处理
                toggle_led();
            }
        }
    }
}

这个代码逻辑非常简单。但你看，CPU只要跑起来，它就一直在那个if判断里转。哪怕用户一年不按按键，CPU也是满负荷运转。这就是最原始的轮询。

2.2 单片机裸机下的轮询模型

刚毕业那会儿，我做过一个温控器项目。单片机采集温度传感器数据，控制加热棒。当时用的就是纯粹轮询模型。结构大概是这样的：

• 初始化阶段：配置ADC、GPIO、定时器。不做多余的事。
• 主循环阶段：读取ADC值 → 换算温度 → 判断是否超限 → 控制继电器 → 延迟100ms → 再读。

你想想看，这个主循环里，100ms的延迟完全是靠delay()函数在那空转。CPU什么都没干，但功耗降不下来，响应速度也被锁死在这个周期里。

2.3 轮询 vs 中断：关键分水岭

很多人一提到轮询就觉得它「不好」。其实不是轮询不好，是用错了地方。

我整理过一个对比表，直接看吧：

对比项	轮询 (Polling)	中断 (Interrupt)
触发方式	CPU主动查询	硬件主动通知
CPU占用	持续占用（即使无事发生）	仅在事件到来时占用
延迟表现	固定延迟（由轮询周期决定）	微秒级响应
代码复杂度	低，线性逻辑	中等，需考虑重入与优先级
适用场景	简单任务、高频周期检查	突发事件、低功耗场景
经典例子	按键扫描、ADC轮询	外部中断、UART接收中断

这里有个我踩过的坑。我曾经做一块智能锁主板，用轮询去读指纹模块的串口数据。结果每次轮询周期太长，导致手指按上去了，指纹数据读了一半又断了。改成中断接收后，问题立刻解决。

但注意：中断不是万能的。如果事件极其密集（比如每秒几十万次），中断上下文切换的开销可能会比轮询还大。这时候，混合模型才是正解。

2.4 现代操作系统下的轮询进化

从单片机跳到一个跑Linux的服务器上，轮询的概念完全变了。为什么？因为操作系统有进程调度、有DMA、有缓存一致性协议。你写的那个while(read)，放到内核里，远比你以为的复杂。

2.4.1 从阻塞读到select/poll

我早期做网络编程，特别喜欢用read()阻塞。简单，写起来很舒服。但它的问题是——一个线程只能伺候一个fd。如果要同时监听十几路socket，那就得开十几路线程。性能开销一下就上去了。

// 早期的做法，每个fd一个线程
void* worker(void* arg) {
    int fd = *(int*)arg;
    char buf[1024];
    while (1) {
        int n = read(fd, buf, sizeof(buf));
        if (n > 0) {
            process(buf, n);
        }
    }
}

后来有了select()和poll()。它们做了一件关键的事：让单线程可以轮询多个文件描述符。这确实是一个进步。但我用select踩过一个坑——它的fd上限只有1024。有一次线上服务连接数刚过1000，直接爆炸。

机制	最大fd数	时间复杂度	触发模式
select	1024	O(n)	水平触发
poll	无上限	O(n)	水平触发
epoll	无上限	O(1)	水平/边缘触发

2.4.2 epoll：真正的现代轮询

个人认为，epoll是Linux下最优雅的轮询方案。它没有select的1024限制，也不像poll那样每次都要把整个fd集合拷进内核。epoll只拿发生变化的那部分事件给你。

我参与过一个IM网关项目，需要同时维持10万条长连接。如果用select，光是遍历fd列表就得用掉几百毫秒。用epoll后，几乎无感。为什么会这样？因为epoll是事件驱动，不是遍历驱动。它只在核心建立了回调机制，真正做到了「有变化才通知」。

看这段业界通用的核心模式：

int epfd = epoll_create1(0);
struct epoll_event ev, events[MAX_EVENTS];
ev.events = EPOLLIN;
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &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) {
            // 新连接
        } else {
            // 读写数据
        }
    }
}

这里epoll_wait就是内核级的轮询。但它跟单片机的while(1)完全不同。它不会空转，如果没事件，内核会让出CPU给其他进程。这就是操作系统对轮询的根本性改造——让轮询变得可休眠、可缩放、可感知优先级。

2.5 轮询的代价：不止是CPU

很多人觉得轮询只浪费CPU。实际上远不止。

• CPU占用：无意义地占用执行单元，导致其他任务被延迟。
• 缓存污染：空轮询会频繁访问内存，把L1/L2 cache里的有效数据冲洗掉。我们团队有次排查一个服务性能抖动，最后定位到是空轮询导致的热数据被逐出。
• 功耗问题：在移动设备或嵌入式场景下，纯轮询会让芯片无法进深度休眠。我修过一个智能手环待机短的问题，最后发现是心率传感器的轮询线程没有休眠回调。
• 可伸缩性：当连接数从100涨到10000，轮询的复杂度如果是O(n)，那性能衰减是指数级的。

2.6 一张图看懂轮询演进

我把从单片机到现代操作系统的轮询路径画了出来。你一看就明白：

2.7 总结

轮询不是一个过时的概念。恰恰相反，你写的大部分高并发框架，底层都依赖某种形式的轮询——只不过它是被优化过的、有休眠通知机制的轮询。

我个人觉得，真正重要的是认清轮询的本质：主动问询。在资源受限的嵌入式场景，合理设计轮询周期可以兼顾响应与功耗；在服务端场景，用epoll替代select可以轻松支撑十万并发。轮询没有好坏，只有合不合理。