如果你写过 Java 的 Socket 服务，多半写过这种结构：一个 while(true) 里 accept，然后为每个连接开一个线程。几十个连接时看不出问题，几百个连接时线程切换开始拖慢响应，上千个连接时内存直接顶不住。问题不在于代码写得丑，而在于这个模型本身在高并发下不成立。这门课要解决的，就是这个具体的缺口。

先确认你缺的是哪一块

Reactor 服务器不是"再学一个框架"，它考的是一组前置能力。如果你的短板在下面任何一项，看这门课之前得先补上，否则会卡在中途：

能熟练用 Java NIO 写 Selector 循环，知道 OP_ACCEPT、OP_READ、OP_WRITE 分别什么时候触发；
理解阻塞、非阻塞、同步、异步这四个词各自的边界，不是背概念，而是能说清一次 read 调用在什么情况下会让线程挂住；
拆得开 TCP 粘包和半包，知道为什么必须自己维护读缓冲区；
对线程池、缓冲区（ByteBuffer）的读写指针切换不陌生。

这几项里，NIO 是硬门槛。Reactor 本质上就是把 Selector 的事件循环、线程模型和业务处理拆开再重新组合，不懂底层事件怎么来，看设计模式只会觉得绕。

单 Reactor、多 Reactor、主从 Reactor，区别在哪

课程的主线是演进，不是直接甩给你一个最终架构。这里最值得盯住的是三个问题：

为什么单 Reactor 单线程在连接数上来之后会崩——瓶颈到底落在 accept、read 还是业务计算上；
多线程 Reactor 把业务处理丢进线程池后，为什么反而可能引入新的竞态和上下文切换开销；
主从 Reactor 把 accept 和读写分离到不同线程组，解决了什么、又付出了什么代价。

能把这三次演进的取舍讲清楚，比记住某个现成框架的 API 有用得多。因为换一个场景，你需要自己判断该用哪一档。

练习怎么跟上

这类内容光看会骗自己。跟着课程动手时，建议盯几个可验证的指标：

用压测工具逐步增加并发连接数，观察单 Reactor 模型在哪一档开始出现延迟陡增；
把业务处理改成 sleep 模拟耗时操作，看线程池模型下主线程是否真的不被阻塞；
故意发送分片数据，验证自己的解码逻辑能不能正确处理半包；
连接断开时检查 SelectionKey 有没有正确取消，避免空轮询把 CPU 打满。

这几个练习不需要多复杂的工具，一个本地压测脚本加日志就能看出差别。重点是自己制造问题再定位，而不是跑通示例就往下翻。

看完应该能回答的问题

用这几个问题自查，答不上来就说明那一节还没吃透：

Selector 空轮询是怎么产生的，JDK 里有哪些已知的坑，业务代码层面怎么规避；
一个连接从 accept 到注册读事件，中间经历了哪些步骤，哪一步可能丢事件；
写事件为什么不能一直注册，什么时候该注册、什么时候该取消；
如果业务处理是 CPU 密集型的，Reactor 线程模型该怎么调；
你的服务器在 1 万连接下，内存主要花在哪里，怎么估算。

这门课不承诺让你变成架构师，它处理的是一个明确的能力缺口：从"能写出跑得通的服务"到"知道它在压力下会怎么坏、以及怎么让它不坏"。有 Java 基础、正在被并发量问题困扰的人，可以把这门课当成一次带着问题的补课，而不是一次从头学起。