Catching memory leaks with Chrome DevTools
当分配的内存没有返回给操作系统或内存池时，我们将其称为内存泄漏。 在这种情况下，内存未被任何应用程序使用，并且被不必要地占用。 这会导致低性能、高延迟和频繁崩溃。
Understanding memory leaks
如果您熟悉 C 等低级语言，您一定使用过 malloc() 和 free()。 相比之下，JavaScript 在创建对象时自动分配内存，并在不再使用时释放它。
好吧，因为它是自动管理的，所以我们作为开发人员总是有一个错误的印象，即我们不需要担心浏览器中的内存管理。 如果一个站点使用越来越多的内存，这意味着没有人收集它并且存在内存泄漏。
Garbage collectors
如果垃圾收集器 (GC) 是完美的，那么内存泄漏就不是问题。 问题是他们的算法不够聪明，无法检测内存泄漏。 因此，需要人工干预。
垃圾收集器执行查找程序不再使用的内存并将其释放回操作系统以供将来重新分配的过程。 该方法有效，但仍然会发生内存泄漏。 该方法无法检测每个泄漏，例如泄漏的引用。
Why is there a memory leak?
下列是几种常见的内存泄漏类型。
Accidental global variables
这里的 this 指的是 window 对象，因此这个变量将在 window 中创建。
由于全局变量不是由 GC 收集的，如果此字符串变得太大，可能会导致内存泄漏。 意外全局变量的一个类似示例是在不使用 let 和 var 关键字的情况下声明变量。
Detached DOM nodes
分离 DOM 节点是一个关键问题。 由于全局引用，分离的节点仍然存在于内存中。
Tools to identify memory leaks
意外的全局变量 内存泄漏可以通过分析轻松检测到。 我们举一个代码片段的例子，它会因为全局变量而导致内存泄漏。
例子：
Allocation profiler
Allocation Timeline 是另一个工具，可以帮助您跟踪 JS 堆中的内存泄漏。 要记录时间线，请转到您的 profile 面板，然后单击上面给出的相同代码的开始。
当我们单击如图所示的开始按钮并使用分配分析器进行配置时，我们可以看到它生成了如图所示的蓝线。
蓝条代表新的内存分配，这可能是内存泄漏。 您可以通过缩放这些蓝色条中的任何一个来查看详细信息。 此处的详细信息表示被推入数组且从不进行垃圾回收的长字符串。
