事件循环重新分配等待期间的资源

[[Thread-per-request模型与并发上限]]的根本浪费在于：线程发起一次数据库调用后，在等结果返回的这段时间里被完全闲置，既不能处理别的请求，也没在做任何有用的工作。事件循环模型换了个思路：发起 I/O 调用时不阻塞线程，而是注册一个回调就把线程还回去处理别的请求，等数据真正就绪时再通知，由某个空闲线程去执行这个回调——同一个线程在等待窗口里可以持续被复用去处理其他请求。这就是为什么响应式应用默认配置每个 CPU 核心只需要一个线程：并发请求数不再和线程数量线性绑定，因为线程不再因为等 I/O 而被占用。发散：这解释了为什么响应式对”I/O 密集型”场景（频繁调数据库、调下游服务）收益巨大，对纯计算密集型场景几乎没有意义——计算密集型任务本来就没有”等待期间被浪费”这个问题，事件循环解决的问题根本不存在。