JavaScript：2011 年我应该担心内存泄漏吗？

Question

JavaScript 中的内存泄漏这个话题并不经常被提及。然而，我偶然发现了这篇文章，写于 2007 年。作者状态：

Internet Explorer 和 Mozilla Firefox 是最常用的两种 Web 浏览器 通常与 JavaScript 中的内存泄漏相关。

2011 年我还应该担心 JavaScript 内存泄漏吗？如果是这样，我应该注意什么？

Answer 1

优秀的 JavaScript 开发人员会意识到可能导致内存泄漏的各种设计模式，并且您会避免在几乎所有编码的页面中编写可能导致泄漏的任何内容。

例如，在 javascript 变量中保留对任何 DOM 对象的引用将使该 DOM 对象在内存中保持活动状态，即使它早已从 DOM 中删除并且您打算释放它。

实际上，泄漏仅在某些情况下才显着。这是我特别担心的地方：

1. 我在计时器上重复做的任何事情，特别是如果它可以长时间运行的话。例如，如果您有一个可能会永远循环的幻灯片，则必须绝对确保幻灯片中没有任何内容是 JS 或 DOM 对象的累积泄漏。
2. 一个像应用程序一样工作的网页，用户可能会长时间停留在同一页面上，与页面交互，执行 ajax 调用等......例如，一个网络邮件应用程序可能打开并在同一个实际浏览器上文档很长一段时间进行大量的用户和服务器交互。
3. 定期创建和销毁大量 DOM 元素的网页，就像定期使用 ajax 获取一堆新 HTML 的网页一样。

我并不真正担心泄漏的地方：

1. 没有用户可以执行的长时间运行的交互集的网页。
2. 在加载其他页面或重新加载此页面之前，网页不会在屏幕上停留很长时间。

我密切关注的一些关键事项。

1. 创建/销毁 DOM 元素时包含对 DOM 元素的引用的任何持久 JS 变量或属性。
2. 包含对其他 DOM 对象的引用的 DOM 对象的任何属性，或对包含对其他 DOM 对象的引用的 JS 对象的引用（这可能会在 JS/DOM 之间创建循环引用和交叉引用，某些较旧的浏览器无法释放这些引用）。
3. 我加载供临时使用的任何大型数据结构。我确保不保留对这些大型数据结构的引用。
4. 任何数据缓存。确保没有缓存任何您不想缓存的大数据。确保所有重复使用的缓存不会永远累积，并具有某种老化机制来清除旧对象。

Answer 2

是的，内存泄漏绝对是 JavaScript 中的一个问题，因为循环引用确实是可能的。内存泄漏的一个非常常见的来源是闭包的使用。举个例子，考虑一下：

var outerFunction = function(param1, param2, param3) {
     var innerFunction = function() {};
     return innerFunction;
};

上面的代码有可能泄漏参数，因为 innerFunction 保存了对其构造范围的引用，其中包括该框架的参数。

虽然在许多有大量 RAM 的台式计算机上，这些事情很容易被忽视，但实际上，在 RAM 有限的设备（例如移动电话或机顶盒）上，这一点可能非常明显。举个有趣的例子，当我从 RAM 非常有限的电视上访问一些未命名的网站时，我经常崩溃。

请注意，这些问题与 Web 开发人员编写的 JavaScript 代码有关。底层 JavaScript 解释器中的内存泄漏虽然可能存在，但远不是一个问题，而且 Web 开发人员不必担心，因为这是浏览器编写者的工作。

Answer 3

不。

更完整的答案：也许吧。您问得如此含糊，这是一个强烈的信号，表明您个人不太可能需要担心。

实际上，绝大多数 JavaScript 代码根本不担心它，也不需要担心它，因为只有在特定情况下，页面中的内存泄漏才会最终影响用户。浏览器和框架很好地覆盖了你的屁股。

您只需回答几个问题：

问：您是否支持大量使用 JavaScript 的丰富单页应用程序？

如果没有，那就不要浪费时间担心。如果您（或您的质量检查或您的客户）发现页面存在内存过度使用问题，请在出现问题时修复它。

问：你们需要支持移动设备吗？并且你们大量使用 javascript 吗？

移动设备的内存有限，需要格外小心。

如果您正在开发一个 JavaScript 密集型应用程序，并且需要担心内存使用情况，那么...

对对象的“脏”引用问题会导致 JavaScript 对象和 DOM 对象永远不会被垃圾收集对于某些类型的 JavaScript 应用程序很重要。永久增长的缓存、意外的全局引用以及闭包内意外的引用都可能是一个问题。

Chrome 的 Web Inspector 中的堆快照工具可以提供帮助。

这是一个 git 项目，它有一个有用的 writup 并可以遍历 javascript 对象： https://github.com/ tlrobinson/leakhelper

还有其他工具可以帮助您，但随着时间的推移，我编写了自己的工具：
1.我们的框架标记了已删除的小部件，因此我编写了代码来从窗口或文档中遍历所有数组和对象，查找到已删除对象的路径（JavaScript 代码无法遍历闭包，但它确实有助于发现一些泄漏）。
2.我使用的另一个技巧是当小部件 x 被删除时，我执行 x.leakhelper = window.createElement('leakhelper') 并 setAttribute 小部件的 oid，但不将元素添加到文档中。如果 DOM 元素没有被垃圾回收，那么小部件必须在某处有一个对其的悬空引用。在 IE 中使用 window.collectGarbage() 强制进行 GC，并使用 sIEve 来检测泄漏的 DOM 元素（我发现 sIEve 非常有用）。

过时的问题：您是否需要大力支持 IE6 或 IE7 并且您大量使用 JavaScript？您过去读到的大多数可怕的泄密事件仅发生在 << IE8。如果您支持 IE6 或 IE7，那么您需要好运和毅力（所有框架都会泄漏，并且即使使用完美的框架也很难编写不兼容的代码 - 我最终编写了自己的 IE 防泄漏代码供我们的生产使用适用于 IE6/7 用户）。即使您关闭页面，IE6/IE7 的泄漏也会持续 - 这就是它们如此令人讨厌的原因。

Answer 4

好吧，人们仍然使用旧版本的 IE。所以要小心循环引用，因为 IE 在这方面有严重的问题。我认为在这方面常见的错误是在事件处理程序内部的闭包中引用该元素的 HTML 元素。只需将引用该元素的变量设置为 null 就可以了。

Answer 5

这实际上取决于两件事 -

1. 应用程序的平均运行时间期望。在线商店主页上的简单 jquery 灯箱或轮播可能会泄漏（并且经常这样做，因为它们的编码非常糟糕），但没有人会注意到（因为页面在几分钟或更短的时间内关闭或刷新）。但是 Node.js 服务器、全 ajax 社交网络、浏览器游戏或在线 IDE - 可以不间断地运行数小时甚至数天。

2. 应用程序的

   I/O 复杂性。你接触 DOM、XHR/网络、文件、DOM/UI 事件的次数越多，重绘屏幕的次数就越多（无论是 canvas、html 还是 svg）——泄漏、内存占用的风险就越大（这不是泄漏）并遇到浏览器错误。

对你来说有好处的是——这两件事是相互关联的。因此，您要么像没有明天一样编写铲子代码，要么针对性能、耐用性和稳健性进行工程师。

ps：如果你非得支持IE8-，那你还不到2011年。所以你只需要担心，就像过去的美好时光。