为什么在 for 循环中声明的变量的最后一次迭代没有被垃圾收集？

如何解决为什么在 for 循环中声明的变量的最后一次迭代没有被垃圾收集？

我的问题是这是否是 nodejs 垃圾收集器错误？或者这在某种程度上是预期的？

在 Windows 上运行 node v14.15.0。

在研究涉及 WeakRef 对象的 this question 的答案时，我发现了一个关于垃圾收集的奇怪事情，这似乎是一个可能的错误。即使在 for 变量超出 let 循环的范围之后，分配给在 for 循环中声明的变量的对象也不会被垃圾回收。这里感兴趣的变量被命名为 element，这是它所在的循环。它只是循环最后一次迭代中的对象没有被 GCed（element 最后指向的那个） :

// fill all the arrays and the cache
// and put everything into the holding array too
for (let i = 0; i < numElements; i++) {
    let arr = new Array(lenArrays);
    arr.fill(i);
    let element = { id: i,data: arr };

    // temporarily hold onto each element by putting a
    // full reference (not a weakRef) into an array
    holding.push(element);

    // add a weakRef to the Map
    cache.set(i,new WeakRef(element));
}

然后，几行代码之后，我们用这个清除数组 holding：

holding.length = 0;

您可能会认为在此循环完成且 holding 已清除后，该循环中 element 的所有值都应符合 GC 的条件。对它们的唯一引用是通过 WeakRef 对象（不会阻止 GC）。

而且，确实，如果我让 nodejs 有一些空闲时间，那么除了 for 循环创建的最后一个对象之外的所有对象都确实是 GCed。但是，最后一个不是。如果我将 element = null 添加到 for 循环的末尾，那么最后一个会被 GCed。因此，即使 element 现在超出范围，nodejs 也没有清除 element 最后指向的变量上的 refcnt。

所以，你可以在这里看到完整的代码（你可以把它放到一个文件中，然后自己在 nodejs 中运行它）：

'use strict';

// to make memory usage output easier to read
function addCommas(str) {
    var parts = (str + "").split("."),main = parts[0],len = main.length,output = "",i = len - 1;

    while (i >= 0) {
        output = main.charAt(i) + output;
        if ((len - i) % 3 === 0 && i > 0) {
            output = "," + output;
        }
        --i;
    }
    // put decimal part back
    if (parts.length > 1) {
        output += "." + parts[1];
    }
    return output;
}

function delay(t,v) {
    return new Promise(resolve => {
        setTimeout(resolve,t,v);
    });
}

function logUsage() {
    let usage = process.memoryUsage();
    console.log(`heapUsed: ${addCommas(usage.heapUsed)}`);
}

const numElements = 10000;
const lenArrays = 10000;

async function run() {

    const cache = new Map();
    const holding = [];

    function checkItem(n) {
        let item = cache.get(n).deref();
        console.log(item);
    }

    // fill all the arrays and the cache
    // and put everything into the holding array too
    for (let i = 0; i < numElements; i++) {
        let arr = new Array(lenArrays);
        arr.fill(i);
        let element = { id: i,data: arr };

        // temporarily hold onto each element by putting a
        // full reference (not a weakRef) into an array
        holding.push(element);

        // add a weakRef to the Map
        cache.set(i,new WeakRef(element));
    }

    // should have a big Map holding lots of data
    // all items should still be available
    checkItem(numElements - 1);
    logUsage();

    await delay(5000);
    logUsage();

    // make whole holding array contents eligible for GC
    holding.length = 0;

    // pause for GC,then see if items are available
    // and what memory usage is
    await delay(5000);
    checkItem(0);
    checkItem(1);
    checkItem(numElements - 1);

    // count how many items are still in the Map
    let cnt = 0;
    for (const [index,item] of cache) {
        if (item.deref()) {
            ++cnt;
            console.log(`Index item ${index} still in cache`);
        }
    }
    console.log(`There are ${cnt} items that haven't been GCed in the map`);
    logUsage();
}

run();

当我运行这个时，我得到这个输出：

{
  id: 9999,data: [
    9999,9999,... 9900 more items
  ]
}
heapUsed: 805,544,472
heapUsed: 805,582,072
undefined
undefined
{
  id: 9999,... 9900 more items
  ]
}
Index item 9999 still in cache
There are 1 items that haven't been GCed in the map
heapUsed: 3,490,168

应该有两行 undefined 行。不需要 id:9999 对象的第二个记录输出。它也应该是 undefined。并且，预计不会发现 id:9999 对象仍在缓存中。它应该有资格进行 GC。

---

一种可能的理论是，V8 优化器将 element 拉出 for 循环，以避免必须在循环内一遍又一遍地创建它，但随后又不使其符合 GC 的条件循环完成 - 本质上是将其提升到更高的范围。

另一种理论是 GC 并不总是块范围粒度。

错误与否？

解决方法

这不是错误。我同意这里的行为乍一看很奇怪，但正如 MDN documentation 所说：

避免依赖规范未保证的任何特定行为也很重要。垃圾收集何时、如何以及是否发生取决于任何给定 JavaScript 引擎的实现。

虽然就 JavaScript 语言语义而言，element 在循环之后超出范围（当然）是正确的，但不能保证/承诺/规范let - 指向的循环（或其他块）中的变量有资格在该块的末尾立即进行垃圾回收。发动机可以自由地例如在内部为这个变量分配一个堆栈槽，它只会在当前函数结束时被清除；和堆栈槽通常被 GC 视为“根”，即它们保持它们指向的东西。

如果无法释放无法访问的对象导致内存无限增长，直到发生 OOM 崩溃，则 这将是一个错误。但这里的情况并非如此：无论您将 numElements 设置为 1、10 还是 10000，它都是 one 对象，它会一直存在到函数结束。

旁注：不需要为了让 GC 运行而休眠 5 秒； Node 的 global.gc() 很好，您还需要返回到事件循环才能看到 WeakRefs 被清除（正如 MDN 文档所指出的那样）。

---

编辑添加：
在这种特殊情况下，最后一个 element 坚持使用的具体原因是因为未优化代码/字节码只是为每个局部变量分配一个堆栈槽。它不会在函数返回之前清空该槽，因此堆栈槽所指的对象将保持活动状态，直到函数返回。这通常（没有 WeakRefs）是不可观察的，并且只是执行速度、启动延迟、内存消耗、CPU/功耗、代码复杂性和/或引擎制作的其他指标之间的众多权衡之一。这些内部细节故意不记录，因为它们可以随时更改，任何人都不应该依赖它们（正如 MDN 文档所指出的那样）。
如果您强制函数 run 在一段时间后进行优化，优化编译器将花时间进行适当的生命范围分析，这通常会导致堆栈槽在函数执行过程中被重用于不同的事情，并且（至少在这种情况下）会导致对象实际上会更快地被垃圾收集。
也就是说，虽然我理解你的好奇心，但我想再次强调：内部细节真的无关紧要。 JS 引擎内部究竟发生了什么在很大程度上取决于整体场景，当然也会根据您运行的引擎和版本而变化。