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 面闆，然後單擊上面給出的相同代碼的開始。
當我們單擊如圖所示的開始按鈕并使用配置設定分析器進行配置時，我們可以看到它生成了如圖所示的藍線。
藍條代表新的記憶體配置設定，這可能是記憶體洩漏。 您可以通過縮放這些藍色條中的任何一個來檢視詳細資訊。 此處的詳細資訊表示被推入數組且從不進行垃圾回收的長字元串。