用这个奇怪的技巧提高 Firefox 的稳定性

我拥有的第一台计算机配备了 128 KiB 的 RAM，直到今天我仍然对应用程序可能会耗尽内存的想法感到震惊，因为即使是 15 岁的机器也经常配备 4 GiB 的内存。然而，它是用户遇到不稳定的最常见原因之一，对于 Firefox 来说，它是 Windows 上崩溃的最大来源。

因此，在 Mozilla，我们花费了大量资源来减少 Firefox 内存消耗并仔细监控变化。在 Windows 平台上花费了一些额外的精力，因为 Firefox 在 Windows 平台上比在 macOS 或 Linux 上更容易耗尽内存。然而，这些努力都没有产生我们在 Firefox 105 中部署的一个很酷的技巧的影响。

但首先，要了解为什么与其他操作系统相比，在 Windows 上运行的应用程序更容易出现内存不足的情况，了解 Windows 如何处理内存非常重要。

所有现代操作系统都允许应用程序分配地址空间块。最初，这些块仅表示不受物理内存支持的地址范围，除非数据存储在其中。当应用程序开始使用它保留的地址空间时，操作系统将专门提供一块物理内存来支持它，如果需要，可能会换出一些现有数据。Linux 和 macOS 都以这种方式工作，Windows 也是如此，只是与其他操作系统相比它需要一个额外的步骤。

在应用程序请求了一块地址空间之后，它需要在能够使用它之前提交它。提交一个范围需要 Windows 保证它总能找到一些物理内存来支持它。之后，它的行为就像 Linux 和 macOS 一样。因此，Windows 限制了多少内存可以提交到机器的物理内存加上交换文件的大小的总和。

此资源（称为提交空间）是应用程序的硬性限制。一旦达到限制，内存分配将开始失败。在操作系统中，这意味着 Windows 不允许应用程序过度使用内存。

该系统的一个有趣方面是应用程序可以提交它不会使用的内存。即使没有数据存储在相应的区域中，因此提交的数量仍将计入限制，因此没有物理内存用于支持提交的区域。当我们开始分析内存不足崩溃时，我们发现许多用户仍然有足够的物理内存可用——有时是千兆字节——但提交空间却用完了。

为什么会这样？我们真的不知道，但我们做了一些有根据的猜测：Firefox 跟踪它使用的所有内存，我们可以说明我们直接提交的所有内存。

但是，我们无法控制 Windows 系统库，尤其是图形驱动程序。我们注意到的一件事是图形驱动程序提交内存以为系统内存中的纹理腾出空间。这允许他们在 GPU 内存不足时将纹理换出，并将它们保留在系统内存中。一种类似于在没有足够 RAM 可用时将常规内存换出到磁盘的机制。实际上，这种情况很少发生，但这些区域仍然计入限制。

我们没有办法直接解决这个问题，但我们仍然有一个王牌：当一个应用程序在 Windows 上用完内存时，它并没有被操作系统彻底杀死，它的分配只是失败了，然后它可以自己决定它做什么.

在某些情况下，Firefox 可以处理失败的分配，但在大多数情况下，没有明智或安全的方法来处理错误，它需要以可控的方式崩溃……但如果我们可以从这种情况中恢复呢？Windows 会在交换文件快满时自动调整其大小，从而增加可用的提交空间量。我们可以利用这个优势吗？

事实证明，答案是肯定的，我们可以。因此，我们将 Firefox 调整为等待一段时间而不是崩溃，然后重试失败的内存分配。这会导致有点卡顿，因为浏览器可能会卡住几分之一秒，但这比崩溃要好得多。

还有另一个角度：Firefox 由多个进程组成，并且可以在失去所有进程（但主要进程除外）的情况下幸存下来。如果内存紧张，延迟主进程崩溃可能会导致另一个进程死亡。这很好，因为它会释放内存并让我们恢复执行，例如通过摆脱内存消耗失控的网页。

如果一个内容进程死了，如果它是 GPU 进程，我们将需要重新加载它，而不是在我们重新启动它时浏览器会短暂闪烁；无论哪种方式，结果都比浏览器完全崩溃的破坏性小。在此之前，我们在 Firefox for Android 和 Firefox OS 中使用了类似的技巧，并且它在两个平台上都运行良好。

这个小技巧在 Firefox 105 中发布，对 Firefox 在 Windows 上的稳定性产生了巨大影响。下图显示了用户在每个活动使用小时内遇到的内存不足浏览器崩溃次数：

您看到崩溃减少了 70% 以上，远远超过我们最乐观的预测。

我们还没有完成！停止主进程导致选项卡崩溃的增加较小——这对用户来说也是不愉快的，即使不像浏览器完全崩溃那么烦人——所以我们也正在减少这些崩溃。

最后但并非最不重要的一点是，我们希望通过对提交空间不足和物理内存不足的情况做出不同的响应来改善低内存情况下的 Firefox 行为，这将减少交换并帮助缩小 Firefox 占用空间其他应用程序的空间。