Node.js运行机制、单线程特性与libuv并发原理相关咨询

你测出来的请求串行排队现象，只有在接口写的是同步CPU密集型代码的时候才会出现——你写的那个跑10秒的循环，是直接把JS主线程（也就是事件循环线程）占满了，这时候线程全程在跑循环计算，根本腾不出手处理事件队列里其他请求的回调，后面的请求自然全堵死。很多资料说Node不适合重计算场景，说的就是同步CPU逻辑会堵死整个事件循环的问题，这和I/O场景下的运行逻辑完全是两码事，别混为一谈。

关于第一个问题：300ms同步计算接口、700并发下最后一个用户是不是要等210秒？ #

• 如果你的接口全是同步CPU计算逻辑，没有任何异步I/O操作，那答案是基本接近这个数值。毕竟主线程被计算占着的时候，新到的请求连触发回调的机会都没有，只能在队列里排着，等前面的请求算完、响应发完，才能轮到下一个请求的逻辑执行。
• 但这个场景在真实线上业务里几乎碰不到：90%以上的业务接口耗时都花在查数据库、读文件、调第三方接口这类I/O等待上，不是纯运算逻辑，这种场景下根本不会出现这种夸张的排队。
• 真要处理重计算逻辑，正常开发者也不会把计算直接写在主接口逻辑里堵主线程，一般会丢给worker_threads开的子线程跑，或者单独拆计算服务，根本不会影响主循环接收新请求。

关于第二个问题：Node高并发优势到底指啥？如果排队等很久这个优势有啥意义？ #

• 常说的Node支持高并发，特指I/O密集型场景下，Node能用极低的资源成本扛住上万的同时在线连接，不会像传统一连接一线程的多线程服务那样，内存占用、线程上下文切换成本跟着连接数线性上涨。
• 举个最常见的例子：如果你的接口是查数据库，单次查询平均耗时300ms，这300ms里Node主线程根本不会傻等数据库返回——它会把查库这个I/O操作丢给libuv处理，立刻转头处理下一个进来的请求，等数据库真的把结果返回来了，再把对应的结果处理、发响应的回调塞回事件队列等着执行。这种场景下700个并发请求根本不用排队，所有查库请求几乎是同时发出去的，最后一个用户的等待时间基本就是单次查库的300ms上下，完全不会累加。
• 你之前测出来的排队，是纯CPU计算堵死主线程的极端场景，根本不在Node高并发优势的适用范围内。这个优势的实际价值就是做web接口、API网关、实时推送这类I/O占比高的服务时，同样的硬件能扛的并发量比传统多线程模型高很多，硬件成本低不少。

关于第三个问题：libuv能同时跑大量I/O，和Node单线程处理逻辑怎么兼容？ #

• 首先别搞混概念：Node说的单线程，是指你写的JS代码是跑在单条主线程上，事件循环本身是单线程轮询队列，不是说整个Node进程就只有一个线程。
• libuv处理异步I/O的逻辑非常直接：碰到JS里发起的I/O操作（比如读文件、网络请求），libuv会直接把操作丢给操作系统提供的异步I/O接口，或者自己维护的工作线程池去跑，主线程完全不等操作完成，直接往下执行下一段JS逻辑。
• 等I/O操作真的跑完了，libuv会把你写的回调（比如处理查库结果、给用户发响应的逻辑）塞到事件循环对应阶段的队列里，等事件循环轮询到这个队列的时候，就把回调拿出来在主线程上跑。
• 说白了，I/O操作的等待、执行过程根本不占主线程的时间，主线程只负责跑你写的JS回调，所以哪怕同时挂着上万个等结果的I/O操作，只要每个回调的JS逻辑跑的足够快（比如几毫秒就能处理完），主线程就不会堵，所有请求都能被快速响应。

内容的提问来源于stack exchange，提问作者Andrey White