V8引擎中递归setTimeout首次调用占满CPU问题咨询

你观察到的性能差异核心是V8的JIT分层编译机制导致的，同时和代码执行逻辑、Chrome性能分析工具的插桩开销也有关，具体原因拆解如下：

1. 首次执行高CPU的原因 #

• V8首次运行未知类型的函数时，会先用解释器Ignition逐行执行字节码，此时没有任何编译优化，你的代码涉及大量Promise微任务调度、递归嵌套的Promise链生成，首次执行时这些对象的分配、类型推断都会产生额外开销。
• 递归poll函数每次调用都会创建新的Promise实例、新的then回调、新的setTimeout回调，首次执行时这些匿名函数都需要被解析、分配内存，如果maxAttempts设置较大，短时间内生成大量临时对象会触发频繁的小内存分配，直接拉高CPU占用。
• 你观测到的调用栈深度差异，是因为首次执行时如果断言函数p()返回同步布尔值，Promise.resolve(p())会直接进入微队列，此时V8还未做相关优化，递归链会被完整保留，调用栈就会累积变深；如果p()是异步返回结果，调用栈会被setTimeout切断，深度就会变浅，所以出现了调用栈深度不一致的情况。

2. 二次执行（刷新后）低开销的原因 #

• V8的即时编译（JIT）会监控高频执行的函数，你的attempt函数和内部的poll函数在首次执行后会被判定为热函数，编译器TurboFan会将其编译为优化后的机器码，去掉了类型检查、字节码解释等额外开销。
• V8会对高频使用的Promise对象、回调函数做内存逃逸分析，你代码里的临时Promise、回调函数如果确定不会逃逸出函数作用域，会被优化为栈上分配，避免了堆内存分配和后续的垃圾回收开销，所以性能工具里几乎观测不到消耗。
• Chrome性能分析工具本身开启时，会给JS执行插桩记录调用栈，首次执行时插桩本身的开销也会被算到函数执行耗时里，二次执行时部分插桩缓存命中，也会显得开销更低。

代码优化建议 #

你可以把计数器直接放到poll的参数里，避免闭包变量的访问开销，同时把等待时长提为可配置项，降低不必要的调度频率：

function attempt<T>(
  f: () => T | Promise<T>,
  p: () => boolean | Promise<boolean>,
  maxAttempts: number,
  wait: number = 50
): Promise<T | null> {
  const poll = (currentAttempt: number): Promise<T | null> => new Promise(
    res => Promise.resolve(p()).then(bool => {
      if (bool) return res(f())
      if (currentAttempt < maxAttempts) {
        return setTimeout(() => res(poll(currentAttempt + 1)), wait)
      }
      return res(null)
    })
  )
  return poll(0)
}

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