要了解記憶體泄漏與記憶體溢位，首先需要了解記憶體是怎么分配的，故此，本文將按照以下幾節闡述：
- 記憶體管理
- 垃圾回收·
- 記憶體泄漏
記憶體管理
JavaScript 是在創建變數（物件，字串等）時自動進行了分配記憶體，并且在不使用它們時“自動”釋放，釋放的程序稱為垃圾回收，這個“自動”是混亂的根源，并讓 JavaScript（和其他高級語言）開發者錯誤的感覺他們可以不關心記憶體管理，
記憶體生命周期基本是一致的：
- 分配你所需要的記憶體
- 使用分配到的記憶體（讀、寫）
- 不需要時將其釋放\歸還
在JavaScript中第一步和第三步都是隱含的
為了不讓程式員費心分配記憶體，JavaScript 在定義變數（值的初始化）時就完成了記憶體分配，
記憶體分配
var n = 123; // 給數值變數分配記憶體
var s = "azerty"; // 給字串分配記憶體
var o = {
a: 1,
b: null
};
// 給物件及其包含的值分配記憶體
// 給陣列及其包含的值分配記憶體（就像物件一樣）
var a = [1, null, "abra"];
function f(a){
return a + 2;
}
// 給函式（可呼叫的物件）分配記憶體
// 函式運算式也能分配一個物件
someElement.addEventListener('click', function(){
someElement.style.backgroundColor = 'blue';
}, false);
有些函式呼叫結果是分配物件記憶體：
var d = new Date(); // 分配一個 Date 物件
var e = document.createElement('div'); // 分配一個 DOM 元素
使用值的程序實際上是對分配記憶體進行讀取與寫入的操作，讀取與寫入可能是寫入一個變數或者一個物件的屬性值，甚至傳遞函式的引數，
當分配的記憶體不再使用時釋放它
大多數記憶體管理的問題都在這個階段，在這里最艱難的任務是找到“哪些被分配的記憶體確實已經不再需要了”，它往往要求開發人員來確定在程式中哪一塊記憶體不再需要并且釋放它，
高級語言解釋器嵌入了“垃圾回收器”，它的主要作業是跟蹤記憶體的分配和使用，以便當分配的記憶體不再使用時，自動釋放它，這只能是一個近似的程序，因為要知道是否仍然需要某塊記憶體是無法判定的（無法通過某種演算法解決），
垃圾回收
垃圾回收演算法主要依賴于參考的概念，在記憶體管理的環境中，一個物件如果有訪問另一個物件的權限（隱式或者顯式），叫做一個物件參考另一個物件，例如，一個 Javascript 物件具有對它原型的參考（隱式參考）和對它屬性的參考（顯式參考），
參考計數垃圾回收
最初級的垃圾回收，此演算法把“物件是否不再需要”簡化定義為“物件有沒有其他物件參考到它”，如果沒有參考指向該物件（零參考），物件將被垃圾回識訓制回收，
限制：無法處理回圈參考的事例，在下面的例子中，兩個物件被創建，并互相參考，形成了一個回圈，它們被呼叫之后會離開函式作用域，所以它們已經沒有用了，可以被回收了，然而，參考計數演算法考慮到它們互相都有至少一次參考，所以它們不會被回收，記憶體發生泄漏
標記清除演算法
這個演算法把“物件是否不再需要”簡化定義為“物件是否可以獲得”，
這個演算法假定設定一個叫做根（root）的物件（在 Javascript 里，根是全域物件），垃圾回收器將定期從根開始，找所有從根開始參考的物件，然后找這些物件參考的物件……從根開始，垃圾回收器將找到所有可以獲得的物件和收集所有不能獲得的物件，
這個演算法比前一個要好，因為“有零參考的物件”總是不可獲得的，但是相反卻不一定，參考“回圈參考”，
從 2012 年起，所有現代瀏覽器都使用了標記 - 清除垃圾回收演算法，所有對 JavaScript 垃圾回收演算法的改進都是基于標記 - 清除演算法的改進，并沒有改進標記 - 清除演算法本身和它對“物件是否不再需要”的簡化定義，
回圈參考只要無法從根出發獲得物件就會被清除
限制：無法從根物件查詢到的物件都會被清除
記憶體泄漏
記憶體泄漏（Memory Leak）是指程式中已動態分配的堆記憶體由于某種原因程式未釋放或無法釋放，造成系統記憶體的浪費，導致程式運行速度減慢甚至系統崩潰等嚴重后果，（程式某個未使用的變數或者方法，長期占用記憶體不會釋放，導致記憶體堆積浪費）參考計數方式對 DOM 物件進行垃圾回收，該方式常常造成物件被回圈參考時記憶體發生泄漏
記憶體溢位:“記憶體溢位(Out Of Memory，簡稱OOM)是指應用系統中存在無法回收的記憶體或使用的記憶體過多，最終使得程式運行要用到的記憶體大于能提供的最大記憶體，此時程式就運行不了，系統會提示記憶體溢位，有時候會自動關閉軟體，重啟電腦或者軟體后釋放掉一部分記憶體又可以正常運行該軟體，而由系統配置、資料流、用戶代碼等原因而導致的記憶體溢位錯誤，即使用戶重新執行任務依然無法避免，”（因為某些原因，程式使用的記憶體大于硬體提供的記憶體，導致記憶體超出了）
————————————————
記憶體泄漏可能的原因
一、全域變數參考
這種問題發生的頻率一般較小, 我覺得應該沒人把全域變數系結到組件上，或者使用變數沒有宣告，
需要注意的是，要盡可能少地宣告全域變數，因為GCRoots的原因，很容易會在查看參考鏈的時候鏈接到window上的屬性，造成干擾，
二、定時器未清除
如果你不確定是不是定時器導致的問題，可以打開【開發者工具】，在Chrome中會有警告
所以養成好習慣，setTimeout使用一定要清除
const timer = setTimeOut(() => {
this.resize()
clearTimeOut(timer)
})
復制代碼
setInterval也是一樣的處理，不過不太建議在代碼里使用setInterval，主要是不太好控制和錯誤捕獲不到，
在平時開發時，可以留意下控制臺里面Chrome發出的warning，去看看背后的原因是什么，一般和性能都是有關系的，這樣會讓你知道怎么樣寫代碼對于瀏覽器來說是沒有問題的，
三、事件未清除
這也是很常見的問題，養成好習慣，
// mounted
window.addEventListener('resize', this.resize)
// beforeDestory
widnow.removeEventListener('resize', this.resize)
復制代碼
這里需要注意最好不要用on的方式去系結事件，覆寫事件以及解綁處理起來會很麻煩，
四、console
生成環境最好不要有console.log，如果有，最好是文字解釋或者格式化后的JSON字串，不要參考當前實體的資料，
五、未添加到Document的dom
function download(url) {
const a = document.createElement('a')
a.href = https://www.cnblogs.com/Allerge/p/url
a.click()
}
如果不手動將a置為null，那么該dom會一直造成泄漏
復制代碼
六、使用一些插件時，未銷毀由該插件生成的dom
比較常用的如Sortable
const sortableInstance = Sortable.create(……)
sortableInstance.destroy()
復制代碼
另外我們自己寫的一些函式，如果生成了dom，或者參考了dom，都要記得銷毀，
let loading = this.$loading({
……,
target: this.$refs.table.el
})
……
loading.close()
loading = null
參考參考：
https://juejin.cn/post/7005110828593020965
https://blog.csdn.net/qq_36359674/article/details/123357844
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/518561.html
標籤：JavaScript
上一篇：TLS握手以及協議詳解