引入TypeScript编译文件后Node.js worker threads并行失效问题排查

核心原因 #

• require操作触发了未被统计的前置耗时：你在worker代码中打印的单任务耗时仅统计了heavyComputation函数的运行时间，但CommonJS规范下，require(xxx)执行时会同步完成「文件读取-语法解析-执行模块所有顶层代码-缓存导出对象」全流程，这部分耗时完全没有被计入你统计的850ms里，相当于每个worker启动后先额外花了几百ms加载模块，才开始执行计算任务。
• 多进程同时加载抢占CPU资源：7个worker进程几乎同时触发大体积模块的加载逻辑，模块加载本身是CPU密集型操作，多进程抢占CPU会导致加载阶段出现排队，进一步拉长了总耗时。
• 额外顶层逻辑放大开销：如果main.js或其依赖的顶层代码存在同步重计算、预生成大缓存、读取大量本地文件这类操作，会进一步增加加载阶段的CPU占用，放大总耗时的涨幅。

排查步骤 #

1. 先确认单进程模块加载耗时：在worker_thread.js的require语句前后增加耗时统计，单独启动一个worker跑一次，就能拿到单个进程加载main.js的实际耗时，如果单个进程加载就要300-500ms，7个并发抢CPU总耗时涨1s以上完全符合预期。

console.time('load main')
const mainApp = require("../../built/src/server/main.js");
console.timeEnd('load main')

2. 检查模块顶层代码：遍历main.js及其所有依赖的顶层作用域，排查是否有立即执行的重计算逻辑，比如预计算常量、初始化大体积实例、批量读取配置等操作，这些都会在require时自动执行。
3. 抓CPU火焰图定位瓶颈：给worker进程启动时加--cpu-prof参数，抓取加载阶段的CPU火焰图，可以直接定位到耗时最高的具体代码段。

解决方案 #

• 懒加载模块：不要在worker顶层requiremain.js，改成实际需要调用它的方法时再执行require，如果worker是复用的，仅第一次处理任务需要加载，后续任务可以直接用缓存的模块对象，完全避免加载耗时影响。
• 优化模块顶层逻辑：把main.js及依赖中不必要的顶层立即执行逻辑，封装成初始化函数，只有主动调用时才执行，不要在require阶段自动运行。
• 提前预热worker池：如果你的场景需要复用worker处理多批任务，可以先启动7个worker，等所有worker都完成模块加载、给主进程返回就绪信号后，再统一下发计算任务，这样任务处理阶段的总耗时就会回到和测试阶段相近的水平。
• 替换为线程模型：你当前用的是child_process.fork生成独立进程，进程本身的启动、资源调度开销比线程更高，可以换成Node.js内置的worker_threads线程模型，降低多实例并发的资源开销。

内容的提问来源于stack exchange，提问作者Greg Cannon