解决方法：Js内存泄漏和解决方案(2)

为了泄漏示例，我们必须在动态创建的元素结构中内联一个脚本函数指针. 设置这些元素之间的相互联系后，这将导致我们泄漏内部临时脚本对象. 由于泄漏很小，因此我们不得不执行该示例数千次. 实际上，对象的泄漏只有几个字节. 在运行示例并将浏览器导航到空白页之后，您将看到两个版本的代码在内存使用方面的差异. 当我们使用第一种方法时，将子元素添加到其父元素，然后添加形成到页面DOM中的子树，我们的内存使用量将略有增加. 这是跨导航泄漏，并且泄漏的内存仅在我们重新启动IE进程时才会释放. 如果使用第二种方法将父元素添加到页面DOM中，然后将子元素添加到其父元素中，则多次运行相同元素后，内存使用量将不再增加，并且您会发现已修复了交叉导航泄漏问题. 内存泄漏插入物干净的插入物这种泄漏类型应予以澄清，因为这种解决方案与我们在IE中的一些有用经验相反. 使用脚本对象及其相关性创建DOM元素是理解此泄漏的关键. 这实际上对于泄漏非常重要，因为如果我们创建的DOM元素不包含任何脚本对象，并且我们以相同的方式将它们关联，则不会泄漏.

示例中给出的第二种技术对于关联的大子树结构可能更有效（因为在该示例中，我们总共只有两个元素，因此构建与页面DOM不相关的树结构将不会产生什么效率）问题）. 第二个技巧是在元素创建开始时不关联任何脚本对象，因此您可以安全地创建子树. 将子树与页面的DOM关联后，继续处理所需的脚本事件. 请记住并遵循有关使用循环引用和闭包函数的规则，在挂接事件时，您的代码将不再遇到不同的泄漏. 我真的很想指出这个问题，因为我们可以看到并非所有的内存泄漏都可以轻易找到. 它们可能是微不足道的问题，但是执行较小的泄漏方案以使问题出现通常需要花费数千倍的时间，就像DOM元素插入顺序引起的问题一样. 如果您觉得自己使用了所谓的“最佳”体验进行编程，则可以坐下来放松身心，但是此示例向我们展示了即使是“最佳”体验也似乎会带来漏洞. 我们这里的解决方案希望改善这些现有的良好体验，或者引入一些新的体验，从而避免泄漏的可能性. 伪泄漏大多数情况下，某些API的实际行为及其预期行为可能会导致您误判内存泄漏. 似乎大多数时间泄漏总是出现在同一页面的动态脚本操作中，并且从页面跳转到空白页面时很少发生这种情况.

然后，您如何排除该问题，就像您排除页面之间的泄漏，以及新任务中的内存使用情况是否符合您的预期. 我们将以重写脚本文本为例，看似是一个泄漏. 与DOM插入顺序问题一样，此问题也需要创建临时对象以生成“泄漏”. 一遍又一遍地重写脚本元素对象中的脚本文本，然后慢慢地，您将开始泄漏所有已链接到覆盖内容的脚本引擎对象. 特别是，与脚本调试有关的对象将保留为完整的代码对象. 内存泄漏插入如果运行上述示例代码并使用任务管理器进行查看，则从“泄漏”页面跳转到空白页面时，您不会注意到任何脚本泄漏. 因为这种脚本泄漏完全发生在页面内部，所以离开页面时将回收使用的内存. 这种情况不利于我们最初预期的行为. 您希望重写脚本内容时，原始脚本对象应该从页面中完全消失. 但是实际上，被覆盖的脚本对象可能已被用作事件处理程序，并且可能还存在一些未清除的引用计数. 如您所见，这看起来像是泄漏. 从表面上看，内存消耗可能看起来很糟，但这是完全可以接受的. 简介每个Web开发人员都可以列出自己的代码示例. 当他们看到列表中的代码时，他们将意识到泄漏的存在，并使用一些开发技术来避免这些问题.

尽管此方法简单方便，但这也是当今网页内存泄漏很普遍的原因. 考虑我们正在讨论的泄漏场景，而不是关注单个代码示例，您将使用更有效的策略来解决泄漏. 这个概念将使您能够在设计阶段估计问题，并确保您有应对潜在泄漏的计划. 养成编写强化代码（译者注: 用于异常处理或清理对象的代码等）的习惯，并采取清理自己的内存的方法. 尽管对于这个问题来说可能太夸张了，但是您几乎永远不会看到在编写脚本时需要清理自己的内存的情况. 使得此问题越来越明显的是script变量和expando属性之间的差异. 存在泄漏的可能性. 如果您对模式和设计感兴趣，我强烈推荐Scott撰写的此博客，因为它演示了消除闭包泄漏的通用示例代码. 当然，这需要我们使用更多的代码，但是这种做法是有效的，并且改进后的场景非常容易在代码中找到和调试. 基于expando也可以使用类似的注入设计

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shoujiruanjian/article-312038-2.html