JavaScript垃圾回收机制概述
在深入探讨Promise的内存行为之前，理解JavaScript的垃圾回收（GC）机制至关重要。JavaScript引擎主要采用“可达性”（reachability）原则来判断一个对象是否应该被回收。如果一个对象可以通过根（例如全局对象、当前执行栈上的局部变量）被访问到，那么它就是“可达的”，不应被回收。反之，如果一个对象不再可达，它就可能被垃圾回收器清除，释放其占用的内存。
Promise与await的工作原理
Promise是JavaScript中处理异步操作的核心机制。一个Promise代表一个异步操作的最终完成（或失败）及其结果值。async/await语法是基于Promise的语法糖，旨在使异步代码看起来更像同步代码，提高可读性。
当一个async函数内部遇到await expression时，它会暂停当前函数的执行，并将expression的值视为一个Promise。此时，await实际上做了以下关键操作：
- 它会等待这个Promise决议（resolve或reject）。
- 它会将当前async函数剩余部分的执行逻辑（即await之后的代码）注册为该Promise的一个回调函数（类似于.then()）。
- async函数立即返回一个挂起的Promise，其状态取决于await的Promise。
这里的关键点在于，await操作并不会从暂停的async函数中创建对被await的Promise的“强引用”，从而阻止该Promise被垃圾回收。相反，是被await的Promise持有了一个对其回调函数（即async函数剩余部分）的引用。
立即学习“Java免费学习笔记（深入）”；
未决议Promise的内存行为分析
考虑到await的工作原理，我们可以直接回答核心问题：如果一个Promise从未决议，并且有async函数在await它，是否会导致内存泄漏？
答案是：通常不会。
如果一个Promise从未决议，但它本身没有被任何可达的变量引用（包括其内部的resolve/reject函数也没有被外部捕获并引用），那么这个Promise对象本身就是不可达的。一旦Promise变得不可达，垃圾回收器就会将其回收。由于该Promise持有对其回调函数（即暂停的async函数执行上下文）的引用，当Promise被回收时，它所持有的这些引用也会随之消失，使得被引用的回调函数上下文也变得不可达，从而一并被垃圾回收。
让我们通过一个示例代码来具体说明：
async function whatHappens() {
console.log('Function started');
await neverResolves(); // 这里的Promise永不决议
console.log('This will never be logged'); // 这行代码永远不会执行
}
function neverResolves() {
// 返回一个永不决议的Promise
return new Promise(() => {
// 这个空函数体意味着resolve和reject回调永远不会被调用
// 并且它们也不会被外部引用，所以它们本身也是不可达的
});
}
// 主线程中反复调用whatHappens
// 模拟大量异步操作
for (let i = 0; i < 100000; i++) {
whatHappens();
}
console.log('Loop finished, check memory usage...');代码分析：
- 在for循环中，每次调用whatHappens()都会创建一个新的async函数执行上下文。
- whatHappens()内部调用neverResolves()，这会创建一个新的、永不决议的Promise实例。
- await neverResolves()会暂停whatHappens()的执行，并将whatHappens()的剩余部分注册为新创建Promise的回调。
- whatHappens()函数本身立即返回一个挂起的Promise，这个Promise在循环结束后如果也没有被其他变量引用，它也会变得不可达。
- 由于neverResolves()返回的Promise没有被任何变量（例如全局变量、数组等）捕获或存储，当whatHappens()调用完成并返回其自身的Promise后，neverResolves()返回的那个永不决议的Promise实例将不再有可达的引用。
- 因此，这个永不决议的Promise及其所持有的对whatHappens()暂停上下文的引用，都将变得不可达，最终会被垃圾回收器回收。
尽管有大量的whatHappens()调用，但由于这些未决议的Promise及其相关的暂停函数上下文最终都会变得不可达，因此不会导致内存泄漏。
潜在的内存泄漏场景（注意事项）
虽然await本身不会导致内存泄漏，但在某些特定场景下，未决议的Promise仍然可能间接导致内存泄漏：
-
外部持有对Promise的强引用： 如果你将这些永不决议的Promise实例存储在一个可达的外部数据结构中（例如一个全局数组、一个长期存在的对象属性），那么这些Promise将永远不会被垃圾回收。由于它们持有对暂停的async函数上下文的引用，这些上下文也将被保留在内存中，从而导致内存泄漏。
const pendingPromises = []; async function whatHappensLeaky() { const p = neverResolves(); // 获取一个永不决议的Promise pendingPromises.push(p); // 存储对Promise的引用 await p; } // 每次调用都会将Promise加入到pendingPromises数组中，导致内存泄漏 for (let i = 0; i < 100000; i++) { whatHappensLeaky(); } -
resolve/reject函数被意外捕获： 当你手动创建new Promise((resolve, reject) => { ... })时，如果resolve或reject函数被某个外部可达的闭包捕获并长期持有，那么即使Promise本身没有直接被引用，这个被捕获的resolve/reject函数也会阻止Promise被垃圾回收。
let externalResolve; function createLeakyPromise() { return new Promise((resolve) => { externalResolve = resolve; // 外部持有resolve函数 // 这个Promise将永远不会被回收，因为它内部的resolve函数被外部引用 }); } const leakyPromise = createLeakyPromise(); // leakyPromise现在被externalResolve间接引用 // 即使leakyPromise本身没有其他引用，它也不会被GC
总结
await一个永不决议的Promise本身并不会导致内存泄漏。JavaScript的垃圾回收机制会正确地识别并回收那些不可达的Promise对象及其相关的暂停async函数上下文。内存泄漏通常发生在开发者不经意间创建了对这些Promise的外部强引用，或者意外地捕获了Promise的resolve/reject函数，从而阻止了它们的垃圾回收。理解Promise的生命周期和JavaScript的垃圾回收原理，是避免这类潜在内存问题的关键。
