[Catching memory leaks with Chrome DevTools](https://medium.com/coding-blocks/catching-memory-leaks-with-chrome-devtools-57b03acb6bb9)

當分配的記憶體沒有返回給作業系統或記憶體池時，我們將其稱為記憶體洩漏。 在這種情況下，記憶體未被任何應用程式使用，並且被不必要地佔用。 這會導致低效能、高延遲和頻繁崩潰。

# Understanding memory leaks

如果您熟悉 C 等低階語言，您一定使用過 malloc() 和 free()。 相比之下，JavaScript 在建立物件時自動分配記憶體，並在不再使用時釋放它。

好吧，因為它是自動管理的，所以我們作為開發人員總是有一個錯誤的印象，即我們不需要擔心瀏覽器中的記憶體管理。 如果一個站點使用越來越多的記憶體，這意味著沒有人收集它並且存在記憶體洩漏。

# Garbage collectors

如果垃圾收集器 (GC) 是完美的，那麼記憶體洩漏就不是問題。 問題是他們的演算法不夠聰明，無法檢測記憶體洩漏。 因此，需要人工干預。

垃圾收集器執行查詢程式不再使用的記憶體並將其釋放回作業系統以供將來重新分配的過程。 該方法有效，但仍然會發生記憶體洩漏。 該方法無法檢測每個洩漏，例如洩漏的引用。

# Why is there a memory leak?

下列是幾種常見的記憶體洩漏型別。

# Accidental global variables

```typescript
function getWork() {
  this.work = “I am Memory leak”;
}
// The this here refers to window object and hence this variable will be created in the window.
getWork();
```

這裡的 this 指的是 window 物件，因此這個變數將在 window 中建立。

由於全域性變數不是由 GC 收集的，如果此字串變得太大，可能會導致記憶體洩漏。 意外全域性變數的一個類似示例是在不使用 let 和 var 關鍵字的情況下宣告變數。

# Detached DOM nodes

分離 DOM 節點是一個關鍵問題。 由於全域性引用，分離的節點仍然存在於記憶體中。
```typescript
var node = document.createElement(‘a’);
node.id = 'id1';
document.body.appendChild(node);
var main = {
   Id: document.getElementById(‘id1’)
}
function removeElement(){
   document.body.removeChild(document.getElementById(‘id1’));
}
removeElement();
```

在上面的例子中，removeChild 函式從樹中移除了 DOM 節點，但是全域性主物件中的引用 Id 仍然保留在記憶體中並且沒有被垃圾收集。

# 閉包

閉包為內部函式維護外部函式變數的範圍，即使在外部函式的範圍之外。

```typescript
function getScore(x) {
   function score(y) {
      return x + y;
    }
   return score;
}
var initial = getScore(2);
var final = initial(3);
```
這裡的函式score，也就是內部函式，有一個全域性引用，叫做initial。 這個初始引用永遠不會被垃圾收集。

# Tools to identify memory leaks

意外的全域性變數 記憶體洩漏可以透過分析輕鬆檢測到。 我們舉一個程式碼片段的例子，它會因為全域性變數而導致記憶體洩漏。
例子：

```typescript
var x = []
var bool = false;
function grow(){
  x.push(new Array(100000).join(‘a’));
  if(bool){
    setTimeout(grow, 1000);
  }
}
function start(){
  grow();
  bool = true;
}
function stop(){
  bool = false;
}
```

到 Chrome 開發者工具裡，開啟 Profiles 標籤頁：

![](https://img-blog.csdnimg.cn/img_convert/b140b2201c237a10d8175517ce7c1ff4.png)

選擇 Take Heap Snapshot.

在這裡，window 物件的黃色實際上描繪了從 JS 程式碼中直接引用的節點。 我們需要修復這裡的程式碼，以便我們可以擺脫黃色標記。

![](https://img-blog.csdnimg.cn/img_convert/9bc02d2fd51556f0fa5b7f083206c500.png)

此處的選項是在函式內將陣列設為區域性，以便垃圾收集器可以收集它或顯式刪除全域性變數。 您可以找到更正後的程式碼：

```typescript
var bool = false;
function grow(){
  var x = [];
  x.push(new Array(100000).join(‘a’));
  
  if(bool){
   setTimeout(grow, 1000);
  }
}
function start(){
  grow();
  bool = true;
}
function stop(){
  bool = false;
}

```

# Allocation profiler

Allocation Timeline 是另一個工具，可以幫助您跟蹤 JS 堆中的記憶體洩漏。 要記錄時間線，請轉到您的 profile 皮膚，然後單擊上面給出的相同程式碼的開始。

當我們單擊如圖所示的開始按鈕並使用分配分析器進行配置時，我們可以看到它生成了如圖所示的藍線。

![](https://img-blog.csdnimg.cn/img_convert/1e175296d26320ea96d534066f5c2946.png)

藍條代表新的記憶體分配，這可能是記憶體洩漏。 您可以透過縮放這些藍色條中的任何一個來檢視詳細資訊。 此處的詳細資訊表示被推入陣列且從不進行垃圾回收的長字串。

使用 Chrome Dev tools 分析應用的記憶體洩漏問題

相關文章