Node.js/Express如何同时处理多个CPU密集型请求？为何会阻塞？

• Express基于Node.js事件循环机制工作，本身没有内置的线程调度逻辑，所有路由匹配、业务代码执行默认都在Node的唯一V8主线程上运行。
• 你写的十亿次空循环是典型的同步CPU密集型代码：这类代码运行时会100%占满主线程CPU，事件循环的任务队列会被完全堵死，根本没有余力接收、解析新的HTTP请求。后到达的请求只能停留在操作系统的TCP连接队列里，直到前一个请求的处理逻辑执行完毕、主线程空出来，才能被路由处理。
• 两类应用表现的差异来自默认模型不同：你本地运行的Flask内置开发服务器默认开启多线程模式，每收到一个请求就会拉起独立的系统工作线程执行视图函数，空循环占用的是独立工作线程的CPU，主线程的请求监听逻辑完全不受影响，因此可以并行处理两个请求、连续打印两次“Begin”。这不是Node天生缺少并行能力，是设计目标的差异。

很多人对“Node单线程”的认知存在偏差：

• Node会把你写的业务代码（包括Express框架本身）绑定在唯一的主线程上执行，但底层依赖的libuv库自带一个默认大小为4的后台线程池。
• 这个线程池的设计用途是卸载I/O密集型阻塞操作：比如原生文件读写、DNS查询、加密计算等，Node会把这类原本会卡住主线程的操作丢给线程池的工作线程执行，主线程全程处理其他任务，等工作线程执行完成后，再把结果通过事件循环投递回主线程执行后续回调。
• 明确的设计红线：libuv的线程池从来不会主动接管你手写的同步业务计算逻辑。哪怕你通过环境变量调大线程池容量，你写的for循环、大段同步数值计算，依然会全程在主线程上跑，不会自动被丢给后台线程。这就是你的请求必须排队的根本原因，和任何配置项都无关。

要让Express应用在处理这类大循环任务时也能正常响应新请求，不需要寻找隐藏的配置开关，需要主动做架构调整：

• 通过worker_threads模块把CPU密集的计算逻辑迁移到独立的工作线程中，主线程仅负责接收请求、转发计算任务、回收结果返回响应，完全不被大段计算阻塞。
• 通过cluster模块启动多进程实例，每个进程拥有独立的主线程和事件循环，进程数和服务器CPU核心数匹配时，就能实现多CPU密集请求的并行处理。

注意：不要为了图省事把同步计算逻辑硬塞进libuv的线程池执行，这种做法违背Node的设计原则，长期运行很容易出现线程池耗尽、响应延迟不可控的问题。

内容的提问来源于stack exchange，提问作者Ihab Abdelkareem