1. 內(nèi)存管理為什么JS開發(fā)者總得懂點(diǎn)這個(gè)如果你寫JavaScript寫過一陣子大概率聽過垃圾回收內(nèi)存泄漏這些詞但真被問到JS里的內(nèi)存管理到底是怎么工作的很多人會(huì)卡殼。這不奇怪因?yàn)镴S這門語言替你扛了絕大部分內(nèi)存相關(guān)的臟活累活——你聲明一個(gè)變量、調(diào)一個(gè)函數(shù)、new一個(gè)對(duì)象背后都有引擎在默默分配和回收內(nèi)存。你不需要像C/C那樣手動(dòng)malloc和free但也正因?yàn)椴挥霉芤坏┏隽藛栴}頁面越用越卡、內(nèi)存爆掉、進(jìn)程被殺反而不知道從哪查起。這篇文章就把JS內(nèi)存管理這塊從頭到尾拆開來講變量聲明時(shí)內(nèi)存怎么分配、對(duì)象和閉包在堆里怎么存活、垃圾回收的標(biāo)記-清除到底怎么運(yùn)作、什么場景最容易制造內(nèi)存泄漏以及排查泄漏時(shí)該看哪些指標(biāo)。不管你是剛?cè)腴T前端的新手還是被線上性能問題折磨過的老手這篇文章都能給你一個(gè)能落地的認(rèn)知框架和排查思路。需要說明的是我這里講的以V8引擎也就是Chrome和Node.js使用的引擎為主因?yàn)樗悄壳白钪髁鳌①Y料也最全的實(shí)現(xiàn)。其他引擎如JavaScriptCore、SpiderMonkey的機(jī)制大同小異核心思路一致細(xì)節(jié)略有差異。先說一個(gè)最基礎(chǔ)的結(jié)論JS的內(nèi)存管理核心就是自動(dòng)分配、垃圾回收、手動(dòng)兜底這三個(gè)詞。自動(dòng)分配由引擎完成垃圾回收也是引擎的周期任務(wù)但手動(dòng)兜底這件事比如排查泄漏、優(yōu)化大對(duì)象、避免閉包意外存活是需要開發(fā)者自己做的。這也是為什么我說懂原理不等于會(huì)寫代碼而是出問題時(shí)知道去哪找答案。在往下讀之前先建立兩個(gè)概念JS運(yùn)行時(shí)把內(nèi)存分成了棧Stack和堆Heap兩大區(qū)域。棧上存放的是基本類型的值和引用類型變量的地址指針特點(diǎn)是分配快、自動(dòng)回收堆上存放的是對(duì)象、數(shù)組、函數(shù)等引用類型的數(shù)據(jù)本體特點(diǎn)是空間大、生命周期不固定是垃圾回收的主要戰(zhàn)場。2. 棧與堆JS數(shù)據(jù)存放的兩大陣營2.1 棧內(nèi)存輕量、快速、函數(shù)級(jí)生命周期棧是函數(shù)執(zhí)行時(shí)的臨時(shí)工作臺(tái)。每調(diào)用一次函數(shù)引擎就會(huì)在棧頂壓入一個(gè)棧幀Stack Frame這個(gè)棧幀里存放著函數(shù)的參數(shù)、函數(shù)體內(nèi)聲明的局部變量、以及當(dāng)前函數(shù)的返回地址。函數(shù)執(zhí)行完畢整個(gè)棧幀直接彈出里面的數(shù)據(jù)隨之釋放。這個(gè)過程極其高效因?yàn)樗簧婕皸ｍ斨羔樀囊苿?dòng)不涉及內(nèi)存塊的掃描和整理。棧上存儲(chǔ)的數(shù)據(jù)類型非常明確——基本類型Primitive Types。在JS里基本類型包括string、number、boolean、null、undefined、symbol、bigint。這些類型的數(shù)據(jù)大小固定數(shù)字8字節(jié)布爾1字節(jié)字符串雖然變化但V8里有專門的字符串表示和優(yōu)化策略引擎可以直接把它們壓在棧上。有一點(diǎn)容易混淆聲明一個(gè)字符串變量棧上存的是字符串的引用還是字符串本身答案取決于引擎實(shí)現(xiàn)和字符串的大小。V8對(duì)短字符串我記得是13個(gè)字符以內(nèi)具體閾值隨版本略有差異會(huì)直接內(nèi)聯(lián)在棧上這叫內(nèi)聯(lián)短字符串長字符串則被放到堆上棧上只保留指針。這屬于實(shí)現(xiàn)細(xì)節(jié)但可以解釋一個(gè)現(xiàn)象——為什么大量拼接長字符串會(huì)導(dǎo)致內(nèi)存壓力那是在堆上不斷創(chuàng)建新字符串對(duì)象。再強(qiáng)調(diào)一遍棧上的內(nèi)存不需要你操心函數(shù)一退出就沒了。真正需要你警惕的是函數(shù)退出了但某些數(shù)據(jù)還被別處引用著——這就是閉包和全局變量的場景它們會(huì)讓本該釋放的數(shù)據(jù)繼續(xù)存活。2.2 堆內(nèi)存大塊頭、長壽命、GC的主戰(zhàn)場堆是JS里所有對(duì)象、數(shù)組、函數(shù)實(shí)例的家。當(dāng)你在代碼里寫const obj { name: Tom }時(shí)棧上的obj變量只保存了一個(gè)指向堆內(nèi)存的地址堆上才真正存放{ name: Tom }這個(gè)對(duì)象。堆內(nèi)存的特點(diǎn)是空間大、可以動(dòng)態(tài)擴(kuò)容、生命周期由引用關(guān)系決定——只要還有地方引用它它就活著沒有任何引用了它就成了垃圾等待GC回收。這引出了JS內(nèi)存管理最核心的問題引擎怎么判斷這個(gè)對(duì)象沒有引用了早期的老牌引擎用引用計(jì)數(shù)Reference Counting每個(gè)對(duì)象記錄自己被引用的次數(shù)次數(shù)歸零就回收。這方案有致命的循環(huán)引用問題——A引用B、B引用A外部沒人用它們了但互相的引用計(jì)數(shù)不為0永遠(yuǎn)無法回收。后來主流的GC算法統(tǒng)一轉(zhuǎn)向了可達(dá)性分析也就是從根Root出發(fā)遍歷所有可達(dá)的對(duì)象不可達(dá)的就是垃圾。堆里再細(xì)分V8還把它分成了新生代New Space和老生代Old Space兩片區(qū)域。新生代是年輕對(duì)象的領(lǐng)地空間小典型配置幾百KB到幾MB垃圾回收特別頻繁老生代是高齡對(duì)象的地盤空間大可以到幾GB甚至更多垃圾回收不頻繁但一旦執(zhí)行就很耗時(shí)。這個(gè)分代設(shè)計(jì)完全是從性能出發(fā)的——絕大多數(shù)對(duì)象的壽命都很短頻繁清理新生代既能保證內(nèi)存可用又不會(huì)讓整個(gè)程序長時(shí)間停頓。2.3 一個(gè)例子看懂?dāng)?shù)據(jù)流轉(zhuǎn)舉個(gè)例子你用Vue或者React寫一個(gè)組件組件的data或state是一個(gè)對(duì)象function createTaskList() { const tasks new Array(1000).fill(null).map((_, i) ({ id: i, title: 任務(wù) i, done: i % 2 0 })); return function getTasks() { return tasks; }; } const getTasks createTaskList(); const currentTasks getTasks();這個(gè)流程里發(fā)生的事情createTaskList執(zhí)行時(shí)函數(shù)棧幀壓棧tasks數(shù)組被創(chuàng)建在新生代堆上。函數(shù)返回了一個(gè)閉包getTasks閉包捕獲了tasks的引用。棧幀雖然彈出了但tasks數(shù)組因?yàn)殚]包還在引用它沒有被回收從新生代晉升到老生代。currentTasks拿到數(shù)組引用后即使getTasks之后不再調(diào)用只要currentTasks還活著tasks數(shù)組就一直存在。這三種狀態(tài)的切換就是堆內(nèi)存管理的日常tasks初始在新生代、經(jīng)歷晉升到老生代、最終生命周期由引用方?jīng)Q定。很多人寫閉包時(shí)沒意識(shí)到閉包會(huì)讓內(nèi)部變量長期存活看到這里應(yīng)該能理解背后的原理了。3. 垃圾回收的核心機(jī)制標(biāo)記-清除與分代回收3.1 從根開始的可達(dá)性分析現(xiàn)代JS引擎的GC核心思路都是標(biāo)記-清除Mark-Sweep的變體。什么叫從根開始根Root是GC遍歷的起點(diǎn)通常包含全局對(duì)象瀏覽器里的window、Node里的global、當(dāng)前執(zhí)行上下文中的局部變量和參數(shù)、調(diào)用棧上的所有引用。GC周期性執(zhí)行時(shí)從這些根出發(fā)沿著引用關(guān)系遍歷所有能觸達(dá)的對(duì)象能觸達(dá)的標(biāo)記為存活觸達(dá)不到的就是垃圾等待清除。這個(gè)設(shè)計(jì)非常巧妙它不關(guān)心這個(gè)對(duì)象被引用了幾次只看從根出發(fā)走不走得到你。循環(huán)引用的問題迎刃而解——A和B互相引用但外部沒有路徑可達(dá)它們那它們就是垃圾整個(gè)引用環(huán)被一起回收。這也是為什么現(xiàn)代JS不用引用計(jì)數(shù)作為主方案。標(biāo)記-清除有兩個(gè)衍生的優(yōu)化版本標(biāo)記-復(fù)制Mark-Compact也叫Scavenge和標(biāo)記-整理Mark-Compact部分實(shí)現(xiàn)會(huì)做整理。標(biāo)記-復(fù)制是把存活對(duì)象復(fù)制到另一塊區(qū)域原區(qū)域整個(gè)清空優(yōu)點(diǎn)是快、適合大量死亡對(duì)象的場景標(biāo)記-整理是在標(biāo)記后把存活對(duì)象往一段挪動(dòng)壓縮碎片適合老生代這種大空間場景。V8的老生代GCFull GC用的就是標(biāo)記整理清除的組合。3.2 新生代的Scavenge機(jī)制V8把新生代分成兩個(gè)半?yún)^(qū)Semi-SpaceFrom空間和To空間。新對(duì)象被分配在From空間當(dāng)From空間快滿時(shí)觸發(fā)Scavenge垃圾回收從根出發(fā)標(biāo)記From空間里的存活對(duì)象。把存活對(duì)象復(fù)制到To空間同時(shí)為每個(gè)對(duì)象調(diào)整年齡經(jīng)歷一次GC的對(duì)象年齡1。清空From空間的所有對(duì)象然后互換From和To的角色。這個(gè)流程對(duì)絕大多數(shù)對(duì)象活不過一次GC的場景極其高效——大部分新對(duì)象在第一次GC時(shí)就被清掉了存活下來的才晉升到老生代。晉升條件有兩個(gè)一是對(duì)象經(jīng)歷了一次Scavenge仍然存活V8通常要求2次視版本而定二是To空間的占用率超過一定閾值比如25%為了給新對(duì)象留空間會(huì)提前把存活對(duì)象推向老生代。Scavenge的缺點(diǎn)很明顯空間利用率低一半空閑所以新生代被設(shè)計(jì)得很小。V8默認(rèn)新生代最大約16MB到64MB取決于堆大小和架構(gòu)。這個(gè)容量限制是有意為之——Scavenge目標(biāo)就是少量復(fù)制高頻回收用空間換時(shí)間。3.3 老生代的標(biāo)記-清除與整理對(duì)象晉升到老生代后GC策略就完全變了。老生代空間大、對(duì)象壽命長如果還像新生代那樣復(fù)制存活對(duì)象成本會(huì)高到難以接受。所以老生代走的是標(biāo)記-清除標(biāo)記-整理標(biāo)記階段從根出發(fā)遍歷整個(gè)圖標(biāo)記所有可達(dá)對(duì)象。清除階段遍歷堆回收所有未標(biāo)記對(duì)象的內(nèi)存把它們釋放回空閑列表Free List。整理階段在需要時(shí)執(zhí)行——把存活對(duì)象向堆的一端移動(dòng)騰出連續(xù)的大塊空閑空間。整理能解決碎片化問題但移動(dòng)對(duì)象意味著所有引用地址都要更新開銷很大所以V8只在空間碎片化嚴(yán)重或分配大對(duì)象失敗時(shí)才觸發(fā)整理。這里有個(gè)值得注意的細(xì)節(jié)老生代GCFull GC會(huì)暫停JS執(zhí)行。因?yàn)镚C期間要移動(dòng)對(duì)象、更新引用如果JS線程同時(shí)在讀寫對(duì)象狀態(tài)就會(huì)錯(cuò)亂。V8的解決思路是增量標(biāo)記Incremental Marking和并發(fā)標(biāo)記Concurrent Marking——把標(biāo)記階段拆成多個(gè)小步穿插在JS執(zhí)行的間隙里跑減少單次停頓時(shí)間清除階段甚至可以在后臺(tái)線程并發(fā)執(zhí)行。這就是你在DevTools Performance面板里看到的長GC任務(wù)Long Task的實(shí)際形態(tài)。說個(gè)直觀數(shù)據(jù)新生代Scavenge通常耗時(shí)零點(diǎn)幾毫秒到幾毫秒老生代Full GC在小頁面幾十MB堆也可能停留幾十毫秒大堆GB級(jí)別可能數(shù)百毫秒。所以框架層有個(gè)約定俗成的優(yōu)化思路——盡量減少長生命周期的大對(duì)象數(shù)量避免頻繁觸發(fā)Full GC。3.4 GC觸發(fā)時(shí)機(jī)與可觀測性GC并不是固定時(shí)間間隔運(yùn)行的它的觸發(fā)時(shí)機(jī)主要看內(nèi)存壓力新生代空間使用率超過閾值約70%~80%時(shí)觸發(fā)Scavenge。老生代空間使用率達(dá)到增長率閾值時(shí)觸發(fā)Full GC。系統(tǒng)內(nèi)存壓力大比如設(shè)備內(nèi)存告急時(shí)引擎可能提前觸發(fā)GC。顯式調(diào)用global.gc()Node.js里需要加--expose-gc參數(shù)強(qiáng)制GC。在瀏覽器里你可以用Performance面板錄制一段交互過程看內(nèi)存曲線和GC長任務(wù)在Node.js里可以用--trace-gc參數(shù)打印GC日志觀察每次GC的堆大小、存活對(duì)象數(shù)和耗時(shí)。這些是后面排查問題時(shí)最基礎(chǔ)的觀測手段。4. 閉包、作用域和事件循環(huán)內(nèi)存泄漏的高發(fā)區(qū)4.1 閉包是如何永久保存變量的閉包是JS最常用的特性之一也是內(nèi)存泄漏最常見的源頭之一。原理很簡單一個(gè)函數(shù)返回后它的局部變量本應(yīng)銷毀但如果這個(gè)函數(shù)內(nèi)部創(chuàng)建了另一個(gè)函數(shù)并且那個(gè)函數(shù)引用了外層變量外層變量就被捕獲了。只要內(nèi)層函數(shù)還有引用比如被存到了全局變量或事件回調(diào)里外層變量就一直活著。function createCounter() { let count 0; return { increment: () count, getCount: () count }; } const counter createCounter(); counter.increment();這里的counter對(duì)象被全局變量持有它的increment和getCount兩個(gè)方法閉包捕獲了count。只要counter不被置空count就會(huì)一直在內(nèi)存里。這不是泄漏是預(yù)期行為。真正的問題在什么時(shí)候出現(xiàn)當(dāng)你只需要用一次某個(gè)閉包卻忘了把持有它的引用置空或者不小心把它放進(jìn)了某個(gè)全局?jǐn)?shù)組、某個(gè)長期存在的事件監(jiān)聽器里這個(gè)變量就變成了意外的常駐內(nèi)存。一個(gè)我踩過坑的案例在某個(gè)管理后臺(tái)里給每個(gè)DOM節(jié)點(diǎn)綁定了click事件的回調(diào)回調(diào)里又引用了一個(gè)超大配置對(duì)象。DOM節(jié)點(diǎn)被移除后事件監(jiān)聽卻沒有被解綁配置對(duì)象和整個(gè)閉包鏈一直被內(nèi)存持有。頁面開了幾十個(gè)標(biāo)簽頁后內(nèi)存曲線肉眼可見地往上走。排查時(shí)用了一個(gè)笨但有效的方法Memory面板里做兩次Heap Snapshot對(duì)比過濾出Detached DOM節(jié)點(diǎn)再查看這些節(jié)點(diǎn)被誰引用——果然事件監(jiān)聽器是元兇。4.2 全局變量與隱式全局全局變量是常駐內(nèi)存大戶因?yàn)樗鼈儚母霭l(fā)直接可達(dá)除非顯式設(shè)為null或undefined否則永遠(yuǎn)不會(huì)被GC回收。很多人忽略的是隱式全局變量——未聲明的變量直接被賦值嚴(yán)格模式下會(huì)報(bào)錯(cuò)非嚴(yán)格模式下會(huì)掛到全局對(duì)象上。function process() { // 忘了寫 let / const / var result fetchSomeData(); // 隱式全局掛在 globalThis 上 }這個(gè)result變量不僅污染了全局命名空間還會(huì)讓fetchSomeData()的返回值一直留在堆里。代碼很難查——你在函數(shù)體里掃一遍根本看不出它被聲明在哪兒而它實(shí)際活在全局作用域。排查這類問題的一個(gè)技巧在代碼里開啟嚴(yán)格模式use strict或者直接用ESLint的no-undef規(guī)則能把隱式全局直接攔下來。另外全局緩存Global Cache也是需要注意的。為了性能很多人會(huì)把數(shù)據(jù)緩存在全局Map里const cache new Map(); function getData(key) { if (cache.has(key)) return cache.get(key); const data fetchData(key); cache.set(key, data); return data; }這個(gè)模式本身沒問題但如果你不清除緩存條目Map里的數(shù)據(jù)會(huì)一直存活。特別是當(dāng)key或value是大型對(duì)象時(shí)無限制的全局緩存就是慢性內(nèi)存泄漏。解決思路是給緩存加容量上限或過期時(shí)間LRU、TTLNode生態(tài)里lru-cache這類庫就是為這個(gè)場景準(zhǔn)備的。4.3 事件監(jiān)聽器綁定一時(shí)爽解綁火葬場瀏覽器的DOM事件、Node.js的EventEmitter事件都是閉包引用鏈的常駐入口。每次addEventListener或on(click, handler)都會(huì)在事件源上建立一個(gè)從全局可達(dá)對(duì)象事件源到回調(diào)函數(shù)的引用鏈。如果不做對(duì)應(yīng)清理回調(diào)函數(shù)以及它閉包里的所有數(shù)據(jù)都會(huì)一直被持有。舉一個(gè)非常常見的React隱患在useEffect里給某個(gè)全局事件源比如window綁定監(jiān)聽器但cleanup函數(shù)沒有正確解綁。useEffect(() { window.addEventListener(resize, handleResize); // 忘記 return () window.removeEventListener(resize, handleResize); }, []);組件卸載后handleResize仍然被window引用如果handleResize閉包捕獲了組件的state或props組件實(shí)例就沒辦法被GC回收造成組件卸載但數(shù)據(jù)殘留的詭異bug。這類問題在React DevTools的Highlight Updates不明顯但堆快照里能看得清清楚楚——搜索組件名你會(huì)發(fā)現(xiàn)已卸載的組件實(shí)例還在堆里躺著。最麻煩的是重復(fù)綁定。每次組件掛載都綁一個(gè)新監(jiān)聽器卸載時(shí)又忘了解綁累積下來監(jiān)聽器數(shù)量翻倍增長內(nèi)存和性能雙雙受害。一個(gè)自查小技巧在代碼里用一個(gè)計(jì)數(shù)器統(tǒng)計(jì)某個(gè)事件源的監(jiān)聽器數(shù)量如果只掛載一個(gè)組件卻出現(xiàn)多個(gè)監(jiān)聽器那基本就是重復(fù)綁定未解綁。4.4 定時(shí)器與網(wǎng)絡(luò)請求的余孽setInterval是內(nèi)存泄漏的經(jīng)典制造機(jī)。它的問題是只要定時(shí)器沒有被clearInterval回調(diào)函數(shù)就會(huì)被持續(xù)執(zhí)行回調(diào)閉包引用的數(shù)據(jù)就永遠(yuǎn)活著。排查時(shí)看到的現(xiàn)象是頁面長時(shí)間運(yùn)行內(nèi)存一點(diǎn)點(diǎn)上升不知道是哪里的數(shù)據(jù)在增長——很可能就是一個(gè)沒人清理的setInterval在周期性分配新對(duì)象。Node.js里還有個(gè)容易忽略的場景Promise或回調(diào)里的定時(shí)器如果Promise成功提前返回而定時(shí)器沒清回調(diào)仍然會(huì)在未來執(zhí)行引用鏈不會(huì)斷。更好的做法是使用AbortController或定時(shí)器ID的統(tǒng)一管理或者在工具函數(shù)層面做封裝確保定時(shí)器和請求都能在合適的時(shí)機(jī)被清理。網(wǎng)絡(luò)請求fetch、XHR、WebSocket也一樣。一個(gè)掛起的請求、一個(gè)沒關(guān)閉的WebSocket連接都可能持有大量的緩沖區(qū)數(shù)據(jù)。特別是請求返回的數(shù)據(jù)量很大比如日志、大JSON響應(yīng)體被閉包引用后這塊內(nèi)存會(huì)一直留著。設(shè)計(jì)請求層的時(shí)候最好把響應(yīng)處理邏輯限制在最小的作用域內(nèi)避免把大數(shù)據(jù)對(duì)象掛在全局或長期對(duì)象上。4.5 不會(huì)再被使用的引用顯式置空一個(gè)老生常談但值得強(qiáng)調(diào)的建議當(dāng)你確定某個(gè)對(duì)象不會(huì)再被使用把它顯式設(shè)為null或undefined。這不是JS GC的必須操作GC會(huì)自動(dòng)判斷可達(dá)性但它能提前斷開引用鏈讓GC在下一輪就能回收而不是等外層容器被清理。尤其在下面幾種場景里格外有用大數(shù)組或大數(shù)據(jù)對(duì)象用完后置空數(shù)組變量。從緩存Map中刪除不再需要的條目。事件監(jiān)聽器解綁后把回調(diào)引用置空。單例或多例實(shí)例不再使用時(shí)置空對(duì)實(shí)例的引用。實(shí)踐中的一個(gè)好處是置空引用能顯著降低GC壓力因?yàn)镚C標(biāo)記階段需要遍歷的對(duì)象更少RAM峰值更低。不過也別過度使用——頻繁手動(dòng)置空會(huì)增加代碼噪音影響可讀性。折中方案是如果數(shù)據(jù)量很大且沖突明顯就值得置空否則保持代碼自然。5. 內(nèi)存泄漏排查實(shí)操從現(xiàn)象到定位5.1 現(xiàn)象觀察卡頓、內(nèi)存攀升、GC頻繁內(nèi)存泄漏最典型的現(xiàn)象是越用越卡——頁面打開時(shí)流暢操作半小時(shí)后明顯卡頓甚至瀏覽器標(biāo)簽頁崩潰。在Chrome任務(wù)管理器ShiftEsc里你可以直接看到每個(gè)標(biāo)簽頁的內(nèi)存占用和觸控進(jìn)程的CPU占用。內(nèi)存占用持續(xù)增長、不回落基本就要往泄漏方向查了。我建議的第一步是記錄內(nèi)存基線。打開頁面后立即記錄當(dāng)前內(nèi)存值然后做一系列常規(guī)操作切換路由、打開關(guān)閉彈窗、增刪列表項(xiàng)操作完再記錄。如果每次操作的峰值比上次高、回落后也不回到基線那就是存在泄漏。這個(gè)操作前后對(duì)比的思路比單純看絕對(duì)內(nèi)存值靠譜得多 — 絕對(duì)內(nèi)存高可能是緩存策略正常的表現(xiàn)但不回落大概率是泄漏。5.2 用Performance面板定位GC長任務(wù)Chrome DevTools的Performance面板錄制一段交互過程然后查看內(nèi)存曲線和時(shí)間軸上的GC任務(wù)。重點(diǎn)關(guān)注內(nèi)存曲線是否呈階梯狀持續(xù)上升而不是周期性回落的鋸齒形。長時(shí)間任務(wù)Long Tasks里是否有明顯的GC大任務(wù)通常顯示為黃色或棕色區(qū)塊。GC頻率如果內(nèi)存曲線還沒怎么漲就頻繁GC說明堆內(nèi)存接近上限可能是泄漏或堆配置不合理。如果步進(jìn)查看每個(gè)GC任務(wù)你還可以看到該任務(wù)的耗時(shí)和回收的內(nèi)存量?；厥樟繕O小但GC卻頻繁往往意味著堆里積壓了大量無用對(duì)象這比單個(gè)大對(duì)象泄漏更隱蔽也更難查。5.3 Heap Snapshot的使用技巧對(duì)比兩次快照Heap Snapshot堆快照是排查泄漏的終極武器。操作流程在頁面上做一次操作前的基線操作等GC穩(wěn)定后錄制第一份Heap Snapshot。執(zhí)行疑似泄漏的操作比如打開關(guān)閉一個(gè)彈窗5次。等待幾秒錄制第二份Heap Snapshot。在快照列表里選擇兩份快照的對(duì)比視圖Comparison按對(duì)象數(shù)差值降序排列。重點(diǎn)查看新增的、無明顯業(yè)務(wù)意義的大對(duì)象、字符串、數(shù)組、Detached DOM節(jié)點(diǎn)。有個(gè)細(xì)節(jié)做快照前最好先手動(dòng)觸發(fā)幾次GCDevTools的垃圾桶按鈕把無關(guān)的臨時(shí)對(duì)象清掉否則對(duì)比結(jié)果里會(huì)混入大量噪聲。我在實(shí)際排查中對(duì)比模式下最常見到的是Detached DOM節(jié)點(diǎn)和字符串增長——前者通常指向未解綁的事件或未清理的DOM引用后者往往是大JSON或日志拼接導(dǎo)致。5.4 Node.js服務(wù)端排查--inspect 與堆快照導(dǎo)出Node.js服務(wù)端的排查思路和瀏覽器類似但手段更靈活。推薦路線啟動(dòng)Node進(jìn)程時(shí)加--inspect參數(shù)然后用Chrome DevTools連接調(diào)試端口9229。用Memory面板做Heap Snapshot流程和瀏覽器端完全一致?；蛘哂妹钚泄ぞ遪ode --inspect配合heapdump模塊在懷疑泄漏的時(shí)間點(diǎn)手動(dòng)導(dǎo)出堆快照文件離線分析。Node服務(wù)端還有個(gè)獨(dú)特場景是服務(wù)生命周期極長線上進(jìn)程可能連續(xù)跑幾周所以緩存、連接池、動(dòng)態(tài)定時(shí)器都要格外小心。我處理過的一個(gè)真實(shí)線上事故某個(gè)微服務(wù)的內(nèi)存每3天漲1GB最后排查到是某個(gè)定時(shí)任務(wù)里每5分鐘創(chuàng)建一次大數(shù)組卻沒釋放引用——數(shù)組引用被存進(jìn)了一個(gè)全局緩存Mapkey不重復(fù)導(dǎo)致Map無限增長。修復(fù)方式就是給緩存加LRU并在業(yè)務(wù)上避免把大數(shù)組長期掛在Map上。5.5 常見問題速查表現(xiàn)象可能原因排查方向修復(fù)建議頁面越用越卡內(nèi)存階梯上升事件監(jiān)聽器未解綁Heap Snapshot搜Detached DOM組件卸載時(shí)解綁或用AbortController長時(shí)間運(yùn)行后內(nèi)存不回落全局緩存無限增長Comparison視圖看Map/Set大小加LRU、TTL、容量上限定時(shí)任務(wù)場景內(nèi)存緩慢攀升setInterval回調(diào)閉包持有大對(duì)象Performance看GC頻率優(yōu)先使用setTimeout鏈?zhǔn)秸{(diào)用并顯式清理Node服務(wù)內(nèi)存持續(xù)上漲全局或模塊級(jí)靜態(tài)變量持有數(shù)據(jù)--trace-gc看GC堆大小確認(rèn)模塊級(jí)變量的生命周期及時(shí)置空每次操作后內(nèi)存峰值遞增高閉包被意外的長期引用比較操作前后的Snapshot縮小閉包作用域用WeakMap/WeakSet大量字符串、數(shù)組對(duì)象無業(yè)務(wù)意義增長拼接JSON、日志或列表未清理按Constructor過濾String/Array避免無界數(shù)組采用滑動(dòng)窗口或分頁5.6 WeakMap與WeakSet給不需要長期存活的數(shù)據(jù)一個(gè)逃生通道這里要專門提一下WeakMap和WeakSet。它們和普通Map/Set的區(qū)別在于對(duì)key的引用是弱引用GC可達(dá)性分析時(shí)不把WeakMap對(duì)key的引用作為存活依據(jù)。換句話說如果某個(gè)對(duì)象只被WeakMap引用沒有任何其他路徑可達(dá)那它就允許被GC回收。這對(duì)緩存與實(shí)例關(guān)聯(lián)數(shù)據(jù)的場景很有用。比如你給某個(gè)DOM節(jié)點(diǎn)掛了一份配置// 直接用MapDOM節(jié)點(diǎn)移除后配置仍然被Map引用內(nèi)存泄漏 const configMap new Map(); function setConfig(node, config) { configMap.set(node, config); } // 改用WeakMapDOM節(jié)點(diǎn)被移除后節(jié)點(diǎn)和配置一起被GC回收 const weakConfigMap new WeakMap(); function setWeakConfig(node, config) { weakConfigMap.set(node, config); }用WeakMap的代價(jià)是它不可迭代、沒有size屬性不能遍歷和統(tǒng)計(jì)。所以它適合一對(duì)一、精確關(guān)聯(lián)的場景不適合需要批量管理的緩存。這是典型的內(nèi)存管理手動(dòng)兜底手段——引擎的GC不關(guān)心業(yè)務(wù)語義開發(fā)者用Weak結(jié)構(gòu)來告訴GC這些數(shù)據(jù)允許被回收。6. 內(nèi)存優(yōu)化的常用手段與長期實(shí)踐6.1 分代策略為什么說多用短生命周期對(duì)象不是罪理解分代GC后你會(huì)發(fā)現(xiàn)一個(gè)反直覺的結(jié)論大量創(chuàng)建短生命周期對(duì)象并不一定是性能問題——新生代回收很快V8對(duì)這類對(duì)象的回收成本極低。真正該避免的是短生命周期對(duì)象被無意中拉長生命周期。比如你在render函數(shù)里創(chuàng)建了一個(gè)超大數(shù)組讓它活著跨過多次GC晉升到老生代然后才被丟棄——這個(gè)晉升過程會(huì)消耗復(fù)制和整理的開銷。優(yōu)化思路有兩個(gè)方向減少大對(duì)象的創(chuàng)建頻率不要在循環(huán)里創(chuàng)建大JSON字符串先在內(nèi)存中組裝好結(jié)構(gòu)化數(shù)據(jù)再序列化。拉長生命周期不代表必須常駐內(nèi)存如果數(shù)據(jù)確實(shí)需要復(fù)用做好緩存策略容量限、過期時(shí)間讓老生代里的數(shù)據(jù)能及時(shí)退出。6.2 字符串拼接與immutable的開銷JS字符串是不可變的。這意味著每次修改字符串比如str a實(shí)際上都創(chuàng)建了一個(gè)新字符串對(duì)象舊的字符串變成垃圾等待GC。在處理大量字符串拼接的場景日志、模板渲染時(shí)這個(gè)開銷會(huì)被放大。V8有一些內(nèi)部優(yōu)化來應(yīng)對(duì)比如字符串扁平化、字符串的延遲拼接但不可變的本質(zhì)不會(huì)變。經(jīng)驗(yàn)之談在Hot Path高頻執(zhí)行的代碼路徑上優(yōu)先考慮Array.join、模板字符串、或流式寫入Node的string stream、瀏覽器的分批渲染而不是頻繁。對(duì)于超大日志輸出直接分塊寫比拼成一個(gè)大字符串再寫要安全得多。6.3 從工具鏈上阻止泄漏ESLint規(guī)則與測試斷言內(nèi)存優(yōu)化不能只靠事后排查最好在代碼review和CI階段就攔截。推薦幾個(gè)可落地的做法ESLint規(guī)則開啟no-undef防止隱式全局browser環(huán)境下的直覺能用規(guī)則檢測。這些不是內(nèi)存專用規(guī)則但很多內(nèi)存泄漏的起點(diǎn)就是這些編碼疏忽。Unit Test中的內(nèi)存斷言在Node.js測試?yán)镉胓lobal.gc()process.memoryUsage()對(duì)比GC前后的堆內(nèi)存斷言內(nèi)存回到基線附近。雖然這類測試容易有噪聲但配合一個(gè)相對(duì)寬松的閾值能攔住大部分明顯的泄漏。Performance Budget在大型團(tuán)隊(duì)里給關(guān)鍵頁面內(nèi)存占用設(shè)預(yù)算例如頁面空閑內(nèi)存不超過某個(gè)值用定時(shí)任務(wù)自動(dòng)檢測和告警。這屬于工程化治理短期成本高但長期效果最好。6.4 NODE_OPTIONS與堆大小調(diào)優(yōu)Node.js里可以顯式設(shè)置堆大小--max-old-space-size和--max-semi-space-size新生代大小。默認(rèn)情況下Node的堆上限通常是2GB64位系統(tǒng)左右如果你的應(yīng)用確實(shí)需要大內(nèi)存比如數(shù)據(jù)處理、每進(jìn)程并發(fā)模型可以調(diào)高node --max-old-space-size4096 app.js但這里要潑一盆冷水調(diào)大堆上限不是解決內(nèi)存問題的萬能藥。堆越大Full GC的耗時(shí)越長停頓越明顯GC停頓導(dǎo)致的延遲反而可能惡化。合理路徑是先通過優(yōu)化代碼減少常駐內(nèi)存讓堆上限保持在一個(gè)合理區(qū)間實(shí)在無法壓下來時(shí)再考慮調(diào)大堆或拆分進(jìn)程。我自己在服務(wù)端調(diào)優(yōu)時(shí)習(xí)慣先把--trace-gc打開跑一天看看Full GC的頻率和耗時(shí)然后以GC頻率低、峰值內(nèi)存可控、單次停頓小為目標(biāo)來配參數(shù)。6.5 用結(jié)構(gòu)避免泄漏設(shè)計(jì)層面的兩個(gè)建議最后分享兩個(gè)偏設(shè)計(jì)層面、但長期效果顯著的建議。第一減少全局可變狀態(tài)。把數(shù)據(jù)盡量封裝在業(yè)務(wù)類或組件的生命周期內(nèi)避免所有數(shù)據(jù)都向全局對(duì)象上掛。全局Map、全局?jǐn)?shù)組、全局事件源都是泄漏的溫床能局部作用域就局部作用域。第二合理使用取消機(jī)制。無論是前端還是Node異步操作請求、定時(shí)、WebSocket都有取消機(jī)制——AbortController、clearTimeout、clearInterval、WebSocket.close()。在代碼設(shè)計(jì)階段就把取消邏輯寫進(jìn)每個(gè)異步操作的代碼塊里而不是事后補(bǔ)救。這一點(diǎn)在我做過的所有線上項(xiàng)目的復(fù)盤里都占了一個(gè)不小的權(quán)重。7. 實(shí)際項(xiàng)目的內(nèi)存排查復(fù)盤一個(gè)富文本編輯器的泄漏案例很多人看完原理覺得懂了真正上手還是懵。我用一個(gè)實(shí)際項(xiàng)目做個(gè)完整復(fù)盤你看完應(yīng)該能建立起從現(xiàn)象到定位到修復(fù)的完整閉環(huán)。模擬項(xiàng)目X是一個(gè)React富文本編輯器支持圖片、表格、提及等復(fù)雜塊。上線兩個(gè)月后運(yùn)營反饋編輯器越用越卡打開超過30分鐘就開始掉幀甚至瀏覽器卡死。我接手排查時(shí)列出的線索是只有長時(shí)間編輯同一篇文檔才會(huì)出問題新建空白文檔沒問題卡頓和文檔內(nèi)容量成正比但刪除內(nèi)容后不會(huì)立刻恢復(fù)流暢。排查過程分三步。第一步先用Chrome任務(wù)管理器觀察內(nèi)存。打開編輯器導(dǎo)入一篇大文檔靜置5分鐘觀察內(nèi)存從120MB慢慢漲到180MB期間一直在點(diǎn)擊工具欄的格式按鈕。說明存在持續(xù)的內(nèi)存增長且和用戶交互相關(guān)。第二步Performance記錄。打開DevTools錄制點(diǎn)擊將內(nèi)容導(dǎo)出為HTML和撤銷重做幾次看到內(nèi)存曲線呈階梯上升每個(gè)臺(tái)階對(duì)應(yīng)一次操作。時(shí)間軸上出現(xiàn)多次Full GC長任務(wù)最長的一次超過200ms——這就是卡頓的直接原因GC暫停了主線程。第三步Heap Snapshot對(duì)比。操作前后各打一份快照對(duì)比模式下發(fā)現(xiàn)兩組明顯的增長一組是大字符串HTML導(dǎo)出相關(guān)另一組是React的Fiber節(jié)點(diǎn)Detached節(jié)點(diǎn)。仔細(xì)看Fiber節(jié)點(diǎn)的保留路徑發(fā)現(xiàn)它們被一個(gè)全局事件總線引用——編輯器的onChange回調(diào)把編輯器實(shí)例掛到了一個(gè)全局總線對(duì)象里而總線對(duì)象從不清理。每次操作觸發(fā)onChange就把新的編輯器快照包含整個(gè)文檔內(nèi)容掛上去舊快照還被總線持有形成一個(gè)操作歷史快照無限累積的泄漏鏈。修復(fù)方案把全局事件總線改成組件局部的事件機(jī)制編輯器實(shí)例不再掛到全局。操作歷史改成有上限的棧比如最多保留50步超出上限的舊快照直接丟棄并把被丟棄快照的引用置空。給編輯器實(shí)例增加destroy()方法組件卸載時(shí)顯式置空所有內(nèi)部引用。修完之后同樣導(dǎo)入大文檔操作30分鐘內(nèi)存穩(wěn)定在140MB到150MB之間Full GC頻率明顯降低卡頓消失。這次排查看起來簡單但每一步都依賴前面對(duì)GC原理的理解——沒有堆快照對(duì)比、沒有對(duì)全局引用會(huì)拉長對(duì)象生命周期的認(rèn)知可能很難想到事件總線是元兇。這個(gè)案例想強(qiáng)調(diào)的核心是JS內(nèi)存管理的重點(diǎn)不是不要?jiǎng)?chuàng)建對(duì)象而是不要讓對(duì)象活得不該活的那么久。理解GC原理的價(jià)值恰恰在于你能判斷出這個(gè)對(duì)象到底該活多久誰在延長它的壽命。我自己在這條路上踩過不少坑有段時(shí)間為了減少GC壓力拼命手動(dòng)置空變量、到處用WeakMap結(jié)果代碼可讀性下降反而引入了新bug。后來我總結(jié)出的原則是優(yōu)先從結(jié)構(gòu)和依賴關(guān)系上解決問題縮小作用域、解除引用、控制緩存把手動(dòng)置空和WeakMap當(dāng)作補(bǔ)充手段而不是首選手段。內(nèi)存管理的本質(zhì)是管理引用而不是管理內(nèi)存本身——引用關(guān)系清晰了內(nèi)存自然健康。