为什么IO多路复用搭配用户态线程（协程/轻量级线程）性能极佳
先理清两个概念：
- IO多路复用（epoll/select）：内核层面，单一线程监听上万连接，解决「多连接多线程」的线程爆炸问题；
- 用户态线程（协程、轻量级线程，如Java虚拟线程、Go goroutine、libco）：切换逻辑不进入操作系统内核，完全在用户空间完成上下文切换。
二者结合后形成双重性能优化，核心原因分6点：
一、普通内核线程的致命开销（对比衬托优势）
传统OS内核线程（Thread）切换流程：
- 线程阻塞/时间片耗尽 → 触发系统调用/时钟中断
- CPU切换内核态，保存全套硬件寄存器、页表、PCB
- OS调度器选新线程，恢复现场，切回用户态
整个过程涉及：用户态↔内核态切换、PCB内存读写、CPU缓存失效，一次切换微秒级开销，上万线程频繁切换CPU直接打满。
而用户态线程切换全程不进内核：
仅保存少量自定义栈/局部变量，无中断、无系统调用，切换纳秒级，开销相差几十上百倍。
二、IO多路复用天然适配用户态线程的调度模型
IO多路复用的工作模式：线程大部分时间阻塞在epoll_wait（内核阻塞），无事件时完全不占用CPU。
结合用户态线程后流程：
- 多个用户态协程共享同一个OS内核线程；
- 协程发起socket读写 → 调用epoll注册fd，主动让出执行权；
- 内核线程阻塞在
epoll_wait等待IO就绪； - 内核通知有fd就绪，唤醒内核线程，调度器在用户态切换到对应协程处理数据。
关键：
所有IO等待交给内核epoll，线程空闲时直接阻塞在内核，不会出现协程空轮询；协程切换只在有IO事件时发生，切换次数极少。
三、内存占用差距巨大，能支撑超高并发连接
- OS内核线程：每个线程默认分配MB级栈（Linux默认8MB），1万线程就要占用80GB内存，机器直接OOM；
- 用户态协程：栈按需动态扩容，初始仅几KB，上万协程内存消耗仅几十MB；
IO多路复用负责承载海量文件描述符，用户态线程负责轻量执行业务逻辑，二者叠加可以单机轻松支持十万、百万TCP长连接（网关、IM、RPC场景）。
四、规避昂贵的「系统调用+上下文切换」双重损耗
如果只用IO多路复用、纯内核线程开发：
多业务场景下需要创建多个OS线程处理就绪事件，IO频繁时会大量触发线程抢占切换。
用户态线程把调度逻辑搬到用户空间：
- IO等待：交给epoll（一次内核阻塞）
- 业务切换：用户态完成，不触发内核调度
大幅减少用户态/内核态往返次数，CPU缓存命中率更高。
五、无锁调度，并发处理成本更低
内核线程之间并发访问共享资源必须加互斥锁，锁竞争会频繁触发内核阻塞；
同一OS线程上的所有用户态协程是串行执行，不存在多核竞争，业务代码可以大幅减少锁使用：
- 只有协程主动让出CPU（IO阻塞）时才切换；
- 临界区代码执行中途不会被强制抢占，规避大量锁开销。
六、分层模型各司其职，性能最大化
| 组件 | 负责工作 | 优势 |
|---|---|---|
| IO多路复用(epoll) | 内核批量监听海量连接，阻塞等待IO事件 | 解决C10K万连接问题，无空轮询 |
| 用户态线程(协程) | 业务逻辑执行、用户态轻量切换 | 极低切换开销、极小内存、无内核调度损耗 |
反面对比两种差方案
- 只用内核线程，不用IO多路复用（BIO）
一连接一线程，线程数量爆炸，内存+切换开销拉满，并发上限极低。 - 只用IO多路复用，单线程同步处理（Nginx单进程模型）
所有业务串行执行，一旦某个业务有CPU密集操作，会阻塞全部连接，无法利用多核；
引入用户态多协程后，可在单内核线程内并发处理多个IO业务，同时多内核线程绑定多核，充分利用CPU。
一句话总结
IO多路复用让大量连接阻塞在内核、避免空轮询；用户态线程把线程切换放到用户空间，省去内核中断、PCB调度的巨大开销；二者结合，既支持百万级并发连接，又拥有极低CPU、内存损耗，是高性能网络服务的标准方案。