Chrome 64.0.3282.140中gc()函数是否为同步函数？技术咨询

首先明确回答你：在Chrome 64.0.3282.140（以及绝大多数基于V8引擎的Chrome版本）中，通过--expose-gc暴露的gc()函数是同步阻塞执行的。也就是说，在你这段代码里：

var memoryBeforeGC = window.performance.memory; 
gc(); 
var memoryAfterGC = window.performance.memory;

当执行到var memoryAfterGC = ...这一行时，gc()已经100%执行完成了，你完全不需要额外设置超时等待。

为什么是同步的？ #

V8引擎的垃圾回收操作本身是会阻塞主线程的——当你调用gc()，浏览器会暂停当前所有JS任务的执行，直到完成完整的垃圾回收流程（包括标记、清除、整理内存等步骤），才会继续往下执行后续代码。这就意味着，gc()调用后的所有代码，都能拿到GC完成后的内存状态。

可以怎么验证？ #

如果你想亲自确认这一点，可以加个时间戳测试：

const start = performance.now();
gc();
const end = performance.now();
console.log(`垃圾回收耗时：${end - start}ms`);

执行这段代码，你会看到输出一个具体的耗时数值——这个时间就是GC全程阻塞主线程的时长，也侧面证明了gc()是同步执行的。

额外注意事项 #

• window.performance.memory默认在Chrome中是关闭的，你需要先在chrome://flags/#enable-memory-info中开启这个选项才能正常获取数据。
• 如果你的代码中存在异步任务持有的未释放内存（比如未完成的fetch请求、定时器回调里的对象），这些对象因为还处于可达状态，GC不会回收它们——但这不是gc()同步性的问题，而是对象可达性的逻辑问题。

关于“如果未完成如何处理”的补充 #

实际上你完全不需要考虑这个情况，因为gc()的同步特性已经保证了后续代码在GC完成后才会执行。如果真的遇到极端场景（比如未来V8版本修改了gc()的执行方式，但可能性极低），你也不需要固定时长的超时等待——更合理的方式是监听内存变化，或者使用requestIdleCallback在浏览器空闲时触发GC并检查状态，但这在当前场景下完全是多余的。

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