[TOC]
# 內存生命周期
不管什么程序語言,內存生命周期基本是一致的:
* 分配你所需要的內存
* 使用分配到的內存(讀、寫)
* 不需要時將其釋放\歸還
所有語言第二部分都是明確的。第一和第三部分在底層語言中是明確的,但在像JavaScript這些高級語言中,大部分都是隱含的。
<br>
<br>
# 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);
~~~
<br>
## 通過函數調用分配內存
有些函數調用結果是分配對象內存:
~~~
var d = new Date(); // 分配一個 Date 對象
var e = document.createElement('div'); // 分配一個 DOM 元素
有些方法分配新變量或者新對象:
var s = "azerty";
var s2 = s.substr(0, 3); // s2 是一個新的字符串
// 因為字符串是不變量,
// JavaScript 可能決定不分配內存,
// 只是存儲了 [0-3] 的范圍。
var a = ["ouais ouais", "nan nan"];
var a2 = ["generation", "nan nan"];
var a3 = a.concat(a2);
// 新數組有四個元素,是 a 連接 a2 的結果
~~~
<br>
## 使用值
使用值的過程實際上是對分配內存進行讀取與寫入的操作。讀取與寫入可能是寫入一個變量或者一個對象的屬性值,甚至傳遞函數的參數。
<br>
## 當內存不再需要使用時釋放
大多數內存管理的問題都在這個階段。在這里最艱難的任務是找到“所分配的內存確實已經不再需要了”。它往往要求開發人員來確定在程序中哪一塊內存不再需要并且釋放它。高級語言解釋器嵌入了“垃圾回收器”,它的主要工作是跟蹤內存的分配和使用,以便當分配的內存不再使用時,自動釋放它。這只能是一個近似的過程,因為要知道是否仍然需要某塊內存是無法判定的(無法通過某種算法解決)。
<br>
V8 實現了準確式 GC,GC 算法采用了分代式垃圾回收機制。因此,V8 將內存(堆)分為新生代和老生代兩部分。
<br>
<br>
# 垃圾回收機制
## 標記清除算法
JavaScript 中最常用的垃圾收集方式是標記清除(mark-and-sweep)。
<br>
這個算法把“對象是否不再需要”簡化定義為“對象是否可以獲得”。
<br>
該算法假定設置一個叫做根(root)的對象(在Javascript里,根是全局對象)。垃圾回收器將**定期從根開始**(在JS中就是全局對象)掃描內存中的對象。凡是能從根部到達的對象,都是還需要使用的。那些無法由根部出發觸及到的對象被標記為不再使用,稍后進行回收。
<br>
此算法可以分為兩個階段,一個是標記階段(mark),一個是清除階段(sweep)。
<br>
### 標記階段
垃圾回收器會從根對象開始遍歷。每一個可以從根對象訪問到的對象都會被添加一個標識,于是這個對象就被標識為可到達對象。
<br>
### 清除階段
垃圾回收器會對堆內存從頭到尾進行線性遍歷,如果發現有對象沒有被標識為可到達對象,那么就將此對象占用的內存回收,并且將原來標記為可到達對象的標識清除,以便進行下一次垃圾回收操作。
<br>

<br>
在標記階段,從根對象1可以訪問到B,從B又可以訪問到E,那么B和E都是可到達對象,同樣的道理,F、G、J和K都是可到達對象。
<br>
在回收階段,所有未標記為可到達的對象都會被垃圾回收器回收。
<br>
### 何時開始垃圾回收
通常來說,在使用標記清除算法時,未引用對象并不會被立即回收。取而代之的做法是,垃圾對象將一直累計到內存耗盡為止。**當內存耗盡時,程序將會被掛起,垃圾回收開始執行。**
<br>
> 從2012年起,所有現代瀏覽器都使用了標記-清除垃圾回收算法。所有對JavaScript垃圾回收算法的改進都是基于標記-清除算法的改進,并沒有改進標記-清除算法本身和它對“對象是否不再需要”的簡化定義。
<br>
### 標記清除算法缺陷
* 那些無法從根對象查詢到的對象都將被清除
* 垃圾收集后有可能會造成大**量的內存碎片**,像上面的圖片所示,垃圾收集后內存中存在三個內存碎片,假設一個方格代表1個單位的內存,如果有一個對象需要占用3個內存單位的話,那么就會導致Mutator一直處于暫停狀態,而Collector一直在嘗試進行垃圾收集,直到Out of Memory。
<br>
## 引用計數算法
這是最初級的垃圾收集算法.現在已經沒有瀏覽器會用這種算法.
<br>
此算法把“對象是否不再需要”簡化定義為“**對象有沒有其他對象引用到它**”。如果沒有引用指向該對象(零引用),對象將被垃圾回收機制回收。
<br>
引用計數的含義是跟蹤記錄每個值被引用的次數。當聲明了一個變量并將一個引用類型值賦給該變量時,則這個值的引用次數就是1。如果同一個值又被賦給另一個變量,則該值的引用次數加1。相反,如果包含對這個值引用的變量又取得了另外一個值,則這個值的引用次數減1。當這個值的引用次數變成0時,則說明沒有辦法再訪問這個值了,因而就可以將其占用的內存空間回收回來。這樣,當垃圾收集器下次再運行時,它就會釋放那些引用次數為零的值所占用的內存。
<br>
### 引用計數缺陷
無法處理循環引用。如果兩個對象被創建,并互相引用,形成了一個循環。它們被調用之后會離開函數作用域,所以它們已經沒有用了,可以被回收了。然而,引用計數算法考慮到它們互相都有至少一次引用,所以它們不會被回收。
<br>
<br>
# Chrome V8 垃圾回收算法
Chrome 瀏覽器所使用的 V8 引擎就是采用的分代回收策略。這個和 Java 回收策略思想是一致的。目的是通過區分「臨時」與「持久」對象;多回收「臨時對象區」(新生代younggeneration),少回收「持久對象區」(老生代 tenured generation),減少每次需遍歷的對象,從而減少每次GC的耗時。
<br>
## 內存限制
**在 Node 中** Javascript能使用的內存是有限制的.
> 1. 64位系統下約為1.4GB。
> 2. 32位系統下約為0.7GB。
<br>
對應到分代內存中,默認情況下。
> 1. 32位系統新生代內存大小為16MB,老生代內存大小為700MB。
> 2. 64位系統下,新生代內存大小為32MB,老生代內存大小為1.4GB。
新生代平均分成兩塊相等的內存空間,叫做semispace,每塊內存大小8MB(32位)或16MB(64位)。
<br>
這個限制在node啟動的時候可以通過傳遞--max-old-space-size 和 --max-new-space-size來調整,如:
<br>
~~~
node --max-old-space-size=1700 app.js //單位為MB
node --max-new-space-size=1024 app.js //單位為kb
~~~
<br>
**述參數在V8初始化時生效,一旦生效就不能再動態改變。**
<br>
## 內存限制的原因
* 表層原因:V8最初為瀏覽器而設計,不太可能遇到用大量內存的場景。
* 深層原因:V8的垃圾回收機制的限制。
* 官方說法,以1.5GB的垃圾回收堆內存為例,V8做一次小的垃圾回收需要50毫秒以上,做一次非增量式的垃圾回收甚至要1秒以上。這是垃圾回收中引起JS線程暫停執行的時間,在這樣時間花銷下,應用的性能和響應能力都會直線下降。
<br>
## V8的分代回收(Generation GC)
V8垃圾回收策略主要基于**分代式垃圾回收機制**。現代的垃圾回收算法中按**對象的存活時間**將內存的垃圾回收進行不同的分代,然后分別對不同分代的內存施以更高效的算法。
<br>
在V8中,主要將內存分為新生代和老生代,**新生代內存 存儲的為存活時間較短的對象**,**老生代內存 存儲的為存活時間較長或常駐內存的對象**,如下圖:

<br>
**V8堆的整體大小就是新生代所用內存空間加上老生代的內存空間。**
<br>
### V8新生代算法(Scavenge)
在分代基礎上,新生代中的對象主要通過Scavenge算法進行垃圾回收。在Scavenge的具體實現中,主要采用了Cheney算法。
<br>
#### Cheney算法
Cheney算法是一種采用復制的方式實現的垃圾回收算法。它將堆內存一分為二,每一部分空間稱為semispace。在這兩個semispace空間中,只有一個處于使用中,另一個處于閑置狀態。**處于使用狀態的semispace空間稱為From空間,處于閑置狀態的空間稱為To空間。**
<br>
當我們分配對象時,先是在From空間中進行分配。當開始進行垃圾回收時,會檢查From空間中的存活對象,這些存活對象將被復制到To空間中,而(From空間內的)非存活對象占用的空間將會被釋放。完成復制后,From空間和To空間的角色發生對換(**即以前的From空間釋放后變為To;To空間在復制存活的對象后,變為From空間**)。簡而言之,在垃圾回收過程中,就是通過將存活對象在兩個semispace空間之間進行復制。
<br>
#### 優點
Scavenge由于只復制存活的對象,并且對于生命周期短的場景存活對象只占少部分,所以它**在時間效率上有優異的表現。** **Scavenge是典型的犧牲空間換取時間的算法,** 所以無法大規模地應用到所有的垃圾回收中。但可以發現,Scavenge非常適合應用在新生代中,因為新生代中對象的生命周期較短,恰恰適合這個算法。
<br>
#### 缺點
**只能使用堆內存中的一半**,這是由劃分空間和復制機制所決定的。
<br>
#### 晉升
實際使用的堆內存是新生代的兩個semispace空間大小和老生代所用內存大小之和。當一個對象經過多次復制依然存活時,它將會被認為是生命周期較長的對象。這種較長生命周期的對象隨后會被移動到老生代中,采用新的算法進行管理。**對象從新生代中移動到老生代中的過程稱為晉升。**
<br>
在單純的Scavenge過程中,From空間中的存活對象會被復制到To空間中去,然后對From空間和To空間進行角色對換(又稱翻轉)。但在分代式垃圾回收前提下,**From空間中的存活對象在復制到To空間之前需要進行檢查。在一定條件下,需要將存活周期長的對象移動到老生代中,也就是完成對象晉升。**
<br>
**晉升條件:**
對象晉升的條件主要有兩個,一個是對象是否經歷過Scavenge回收,一個是To空間的內存占用比超過25%限制。
<br>
**設置25%這個限制值的原因:**
當這次Scavenge回收完成后,這個To空間將變成From空間,接下來的內存分配將在這個空間中進行。**如果占比過高,會影響后續的內存分配。** 對象晉升后,將會在老生代空間中作為存活周期較長的對象來對待,接受新的回收算法處理。
<br>

<br>

<br>
### V8老生代算法(Mark-Sweep && Mark-Compact)
對于老生代中的對象,由于存活對象占較大比重,再采用Scavenge的方式會有兩個問題:一個是存活對象較多,復制存活對象的效率將會很低;另一個問題依然是浪費一半空間的問題。為此,V8在老生代中主要采用Mark-Sweep和Mark-Compact相結合的方式進行垃圾回收。
<br>
#### Mark-Sweep
Mark-Sweep是標記清除的意思,它分為標記和清除兩個階段。與Scavenge相比,Mark-Sweep并不將內存空間劃分為兩半,所以**不存在浪費一半空間的行為**。
<br>
與Scavenge復制活著的對象不同,**Mark-Sweep在標記階段遍歷堆中所有對象,并標記活著的對象,在隨后的清除階段中,只清除沒有被標記的對象。** 可以看出,**Scavenge中只復制活著的對象,而Mark-Sweep只清理死亡對象。** 活對象在新生代中只占較小部分,死對象在老生代中只占較小部分,這是兩種回收方式能高效處理的原因。
<br>
**Mark-Sweep最大的問題**
在進行一次標記清除回收后,內存空間會出現不連續的狀態。這種內存碎片會對后續的內存分配造成問題,因為很可能出現**需要分配一個大對象的情況,這時所有的碎片空間都無法完成此次分配,就會提前觸發垃圾回收,而這次回收是不必要的。**
<br>
#### Mark-Compact
為了解決Mark-Sweep的內存碎片問題,Mark-Compact被提出來。Mark-Compact是標記整理的意思,是在Mark-Sweep的基礎上演變而來的。它們的差別在于對象在標記為死亡后,**在整理的過程中,將活著的對象往一端移動,移動完成后,直接清理掉邊界外的內存。** 下圖為Mark-Compact完成標記并移動存活對象后的示意圖,白色格子為存活對象,深色格子為死亡對象,淺色格子為存活對象移動后留下的空洞。
<br>

<br>
**完成移動后,就可以直接清除最右邊的存活對象后面的內存區域完成回收。**
<br>
**Mark-Sweep、Mark-Compact、Scavenge三種主要垃圾回收算法的簡單對比**
| 回收算法 | Mark-Sweep | Mark-Compact | Scavenge |
| --- | --- | --- | --- |
| 速度 | 中等 | 最慢 | 最快 |
| 空間開銷 | 少(有碎片) | 少(無碎片) | 雙倍空間(無碎片) |
| 是否移動對象 | 否 | 是 | 是 |
從表格上看,Mark-Sweep和Mark-Compact之間,由于Mark-Compact需要移動對象,所以它的執行速度不可能很快,所以在取舍上,V8主要使用Mark-Sweep,**在空間不足以對從新生代中晉升過來的對象進行分配時才使用Mark-Compact。**
<br>
## 增量式標記回收(Incremental Marking)
* 為了避免出現js應用邏輯與垃圾回收器看到的不一致的情況,**垃圾回收的3種基本算法都需要將應用邏輯暫停下來**,待執行完垃圾回收后再恢復執行應用邏輯,這種行為被稱為“全停頓”(stop-the-world)。在V8的分代式垃圾回收中,一次小垃圾回收只收集新生代,由于新生代默認配置得較小,且其中存活對象通常較少,所以即便它是全停頓的影響也不大。但V8的老生代通常配置得較大,且存活對象較多,全堆垃圾回收(full垃圾回收)的標記、清理、整理等動作造成的停頓就會比較可怕,需要設法改善(PS: 若V8的堆內存為1.5GB,V8做一次小的垃圾回收需要50ms以上,做一次非增量式的垃圾回收甚至要1秒以上。)。
* 為了降低全堆垃圾回收帶來的停頓時間,V8先從標記階段入手,將原本要一口氣停頓完成的動作改為增量標記(incremental marking),也就是**拆分為許多小“步進”,每做完一“步進”就讓js應用邏輯執行一小會,垃圾回收與應用邏輯交替執行直到標記階段完成。**
* V8在經過增量標記的改進后,垃圾回收的最大停頓時間可以減少到原本的1/6左右。
* V8后續還引入了延遲清理(lazy sweeping)與增量式整理(incremental compaction),讓清理與整理動作也變成增量式的。同時還計劃引入并行標記與并行清理,進一步利用多核性能降低每次停頓的時間。
<br>
<br>
# 參考資料
[JavaScript內存分配及垃圾回收機制](https://blog.csdn.net/suwu150/article/details/86508878)
[前端面試查漏補缺--(二) 垃圾回收機制](https://juejin.im/post/5c6bba32f265da2db07382cf)
- 第一部分 HTML
- meta
- meta標簽
- HTML5
- 2.1 語義
- 2.2 通信
- 2.3 離線&存儲
- 2.4 多媒體
- 2.5 3D,圖像&效果
- 2.6 性能&集成
- 2.7 設備訪問
- SEO
- Canvas
- 壓縮圖片
- 制作圓角矩形
- 全局屬性
- 第二部分 CSS
- CSS原理
- 層疊上下文(stacking context)
- 外邊距合并
- 塊狀格式化上下文(BFC)
- 盒模型
- important
- 樣式繼承
- 層疊
- 屬性值處理流程
- 分辨率
- 視口
- CSS API
- grid(未完成)
- flex
- 選擇器
- 3D
- Matrix
- AT規則
- line-height 和 vertical-align
- CSS技術
- 居中
- 響應式布局
- 兼容性
- 移動端適配方案
- CSS應用
- CSS Modules(未完成)
- 分層
- 面向對象CSS(未完成)
- 布局
- 三列布局
- 單列等寬,其他多列自適應均勻
- 多列等高
- 圣杯布局
- 雙飛翼布局
- 瀑布流
- 1px問題
- 適配iPhoneX
- 橫屏適配
- 圖片模糊問題
- stylelint
- 第三部分 JavaScript
- JavaScript原理
- 內存空間
- 作用域
- 執行上下文棧
- 變量對象
- 作用域鏈
- this
- 類型轉換
- 閉包(未完成)
- 原型、面向對象
- class和extend
- 繼承
- new
- DOM
- Event Loop
- 垃圾回收機制
- 內存泄漏
- 數值存儲
- 連等賦值
- 基本類型
- 堆棧溢出
- JavaScriptAPI
- document.referrer
- Promise(未完成)
- Object.create
- 遍歷對象屬性
- 寬度、高度
- performance
- 位運算
- tostring( ) 與 valueOf( )方法
- JavaScript技術
- 錯誤
- 異常處理
- 存儲
- Cookie與Session
- ES6(未完成)
- Babel轉碼
- let和const命令
- 變量的解構賦值
- 字符串的擴展
- 正則的擴展
- 數值的擴展
- 數組的擴展
- 函數的擴展
- 對象的擴展
- Symbol
- Set 和 Map 數據結構
- proxy
- Reflect
- module
- AJAX
- ES5
- 嚴格模式
- JSON
- 數組方法
- 對象方法
- 函數方法
- 服務端推送(未完成)
- JavaScript應用
- 復雜判斷
- 3D 全景圖
- 重載
- 上傳(未完成)
- 上傳方式
- 文件格式
- 渲染大量數據
- 圖片裁剪
- 斐波那契數列
- 編碼
- 數組去重
- 淺拷貝、深拷貝
- instanceof
- 模擬 new
- 防抖
- 節流
- 數組扁平化
- sleep函數
- 模擬bind
- 柯里化
- 零碎知識點
- 第四部分 進階
- 計算機原理
- 數據結構(未完成)
- 算法(未完成)
- 排序算法
- 冒泡排序
- 選擇排序
- 插入排序
- 快速排序
- 搜索算法
- 動態規劃
- 二叉樹
- 瀏覽器
- 瀏覽器結構
- 瀏覽器工作原理
- HTML解析
- CSS解析
- 渲染樹構建
- 布局(Layout)
- 渲染
- 瀏覽器輸入 URL 后發生了什么
- 跨域
- 緩存機制
- reflow(回流)和repaint(重繪)
- 渲染層合并
- 編譯(未完成)
- Babel
- 設計模式(未完成)
- 函數式編程(未完成)
- 正則表達式(未完成)
- 性能
- 性能分析
- 性能指標
- 首屏加載
- 優化
- 瀏覽器層面
- HTTP層面
- 代碼層面
- 構建層面
- 移動端首屏優化
- 服務器層面
- bigpipe
- 構建工具
- Gulp
- webpack
- Webpack概念
- Webpack工具
- Webpack優化
- Webpack原理
- 實現loader
- 實現plugin
- tapable
- Webpack打包后代碼
- rollup.js
- parcel
- 模塊化
- ESM
- 安全
- XSS
- CSRF
- 點擊劫持
- 中間人攻擊
- 密碼存儲
- 測試(未完成)
- 單元測試
- E2E測試
- 框架測試
- 樣式回歸測試
- 異步測試
- 自動化測試
- PWA
- PWA官網
- web app manifest
- service worker
- app install banners
- 調試PWA
- PWA教程
- 框架
- MVVM原理
- Vue
- Vue 餓了么整理
- 樣式
- 技巧
- Vue音樂播放器
- Vue源碼
- Virtual Dom
- computed原理
- 數組綁定原理
- 雙向綁定
- nextTick
- keep-alive
- 導航守衛
- 組件通信
- React
- Diff 算法
- Fiber 原理
- batchUpdate
- React 生命周期
- Redux
- 動畫(未完成)
- 異常監控、收集(未完成)
- 數據采集
- Sentry
- 貝塞爾曲線
- 視頻
- 服務端渲染
- 服務端渲染的利與弊
- Vue SSR
- React SSR
- 客戶端
- 離線包
- 第五部分 網絡
- 五層協議
- TCP
- UDP
- HTTP
- 方法
- 首部
- 狀態碼
- 持久連接
- TLS
- content-type
- Redirect
- CSP
- 請求流程
- HTTP/2 及 HTTP/3
- CDN
- DNS
- HTTPDNS
- 第六部分 服務端
- Linux
- Linux命令
- 權限
- XAMPP
- Node.js
- 安裝
- Node模塊化
- 設置環境變量
- Node的event loop
- 進程
- 全局對象
- 異步IO與事件驅動
- 文件系統
- Node錯誤處理
- koa
- koa-compose
- koa-router
- Nginx
- Nginx配置文件
- 代理服務
- 負載均衡
- 獲取用戶IP
- 解決跨域
- 適配PC與移動環境
- 簡單的訪問限制
- 頁面內容修改
- 圖片處理
- 合并請求
- PM2
- MongoDB
- MySQL
- 常用MySql命令
- 自動化(未完成)
- docker
- 創建CLI
- 持續集成
- 持續交付
- 持續部署
- Jenkins
- 部署與發布
- 遠程登錄服務器
- 增強服務器安全等級
- 搭建 Nodejs 生產環境
- 配置 Nginx 實現反向代理
- 管理域名解析
- 配置 PM2 一鍵部署
- 發布上線
- 部署HTTPS
- Node 應用
- 爬蟲(未完成)
- 例子
- 反爬蟲
- 中間件
- body-parser
- connect-redis
- cookie-parser
- cors
- csurf
- express-session
- helmet
- ioredis
- log4js(未完成)
- uuid
- errorhandler
- nodeclub源碼
- app.js
- config.js
- 消息隊列
- RPC
- 性能優化
- 第七部分 總結
- Web服務器
- 目錄結構
- 依賴
- 功能
- 代碼片段
- 整理
- 知識清單、博客
- 項目、組件、庫
- Node代碼
- 面試必考
- 91算法
- 第八部分 工作代碼總結
- 樣式代碼
- 框架代碼
- 組件代碼
- 功能代碼
- 通用代碼