发布订阅和轮询

发布订阅和轮询 都有一个控制器 轮询是本身while 构成控制条件（CPU空转） 而发布订阅 则是有一个独立的控制者 可能是一个独立的控制线程 同时发布 订阅往往和线程的任务线程的阻塞唤醒相关，这时候CPU不会分配无效的时间片出来 同时这个轮询查看状态的逻辑被下移到操作系统对于线程运行队列和阻塞队列的管理和处理逻辑上，轮询的动作被下放到原本的cpu运行管理上了 。

轮询是本身 while 构成控制条件（CPU空转） 发布订阅是有一个独立的控制器，可能是独立的控制线程

  1. 轮询模型： 是由业务代码（语言层）显式编写一个 while 循环，不断检查状态或条件是否满足；这实际上是应用层控制器，在用户态消耗 CPU 周期。

  2. 发布-订阅模型： 一般是系统内某种事件调度器（控制器）维护订阅关系和事件触发逻辑，比如：

  3. Redis 的事件 loop

  4. Kafka 的 broker event loop

  5. Java 中的线程阻塞 + notify 唤醒逻辑

这个“控制器”负责协调何时发、谁该收，而订阅者线程往往是阻塞的，等待事件触发再被唤醒。

发布订阅往往和线程的阻塞唤醒相关，这时候 CPU 不会分配无效的时间片。阻塞线程进入 WAITING 或 BLOCKED 状态后，会从就绪队列中移除，不会参与 CPU 时间片调度；操作系统调度器只会从就绪队列中挑选线程，避免了轮询中的“空转浪费”。这正是发布订阅机制在高并发下更节能、更高效的核心优势。

  • 没错！在发布订阅中，轮询不再由业务线程写 while，而是由操作系统的调度器或 IO 多路复用（如 epoll）机制来“代劳”轮询检查。

  • 比如 epoll 会在内核中监听 IO 状态变化，真正轮询行为在内核态完成，线程只在就绪时被唤醒。比如调度器中的阻塞队列和运行队列，以及其中的轮询逻辑。

  • 所以从业务代码视角看，轮询“消失”了，但轮询本质并没有被消灭，只是被“隐藏”或“下沉”到底层实现中。 优缺点

机制 优点 缺点
阻塞唤醒 - 高效节省 CPU 资源
- 适合高并发和 I/O 密集型场景		 - 实现复杂
- 存在线程唤醒延迟
- 线程切换有开销
轮询 - 实现简单
- 响应速度快（无唤醒延迟）		 - 持续占用 CPU，浪费资源
- 不适合高并发或长时间等待
回到页面顶部