引言

Memory Leak 是最難排查調(diào)試的 Bug 種類之一，因?yàn)閮?nèi)存泄漏是個(gè) undecidable problem，只有開(kāi)發(fā)者才能明確一塊內(nèi)存是不是需要被回收。再加上內(nèi)存泄漏也沒(méi)有特定的報(bào)錯(cuò)信息，只能通過(guò)一定時(shí)間段的日志來(lái)判斷是否存在內(nèi)存泄漏。大家熟悉的常用調(diào)試工具對(duì)排查內(nèi)存泄漏也沒(méi)有用武之地。當(dāng)然了，除了專門(mén)用于排查內(nèi)存泄漏的工具（抓取Heap之類的工具）之外。

對(duì)于不同的語(yǔ)言，各種排查內(nèi)存泄漏的方式方法也不盡相同。對(duì)于 JavaScript 來(lái)說(shuō)，針對(duì)不同的平臺(tái)，調(diào)試工具也是不一樣的，最常用的恐怕還是 Chrome 自帶的各種利器（針對(duì) browser 也好，nodeJS 也好）都有不錯(cuò)的使用體驗(yàn)，網(wǎng)上也有很多使用教程。

這次我想給大家介紹的內(nèi)存泄漏的定位方法，并非工具的使用。而是一些經(jīng)驗(yàn)的總結(jié)，也就是我所知道的 VueJS SSR 中最容易出現(xiàn)內(nèi)存泄漏的地方，如果大家知道更多 VueJS SSR 內(nèi)存泄漏點(diǎn)，可以在評(píng)論處留言告訴更多的人。

難點(diǎn)

遇到過(guò) VueJS SSR 內(nèi)存泄漏的朋友可能知道，針對(duì) VueJS SSR 內(nèi)存泄漏的排查，與普通 NodeJS 和 Browser 平臺(tái)相比是要麻煩很多的。如果你使用了 webpack-dev-server 在本地調(diào)試，你會(huì)發(fā)現(xiàn)常用的內(nèi)存泄漏工具毫無(wú)用武之地，因?yàn)樽ト〉降男畔⒉粌H包括 VueJS SSR 進(jìn)程信息，還包含了 Webpack 的進(jìn)程信息，甚至還有 webpack-dev-server 的各種堆信息。當(dāng)然了，你也可以通過(guò)各種手段來(lái)過(guò)濾掉無(wú)關(guān)的信息，從而只剩下 VueJS SSR 的堆信息。

我在排查我們組項(xiàng)目?jī)?nèi)存泄漏的時(shí)候，動(dòng)用了各種常規(guī)工具，但最終發(fā)現(xiàn) VueJS SSR 的內(nèi)存泄漏有很大可能性出現(xiàn)在以下地方，也就說(shuō)如果，你碰巧也有 VueJS SSR 內(nèi)存泄漏的問(wèn)題，先不要使用內(nèi)存泄漏排查工具，首先從下面幾個(gè)地方著手，看看是否有內(nèi)存泄漏的邏輯。可能直擊要害，節(jié)約時(shí)間。

可能造成泄漏的位置

生命周期處的 beforeCreate/created

以下是 VueJS 開(kāi)發(fā)者看過(guò)無(wú)數(shù)次的說(shuō)明圖，我還請(qǐng)大家再多看一遍

在官方文檔里，有這么一句話：

Since there are no dynamic updates, of all the lifecycle hooks, only beforeCreate and created will be called during SSR. This means any code inside other lifecycle hooks such as beforeMount or mounted will only be executed on the client.

也就是說(shuō) SSR 跟前端繪制一樣，也有生命周期，只不過(guò) SSR 的生命周期里只有 beforeCreate 和 created 。

所以你需要首先排查你的組件的 beforeCreate 和 created 里面是否有內(nèi)存泄漏的代碼，或者他們是否調(diào)用了會(huì)內(nèi)存泄漏的代碼。

路由守衛(wèi)(Route Guards)處

路由也是會(huì)引起 SSR 內(nèi)存泄漏的地方之一

跟生命周期不同，所有的 route guard 都會(huì)在 SSR 運(yùn)行。他們分別都是

• beforeEach
• beforeRouteUpdate
• beforeEnter
• beforeRouteEnter
• beforeResolve
• afterEach
• beforeRouteEnter

Data-Prefetch 處

還需要特別注意的地方就是 Date-prefetch 的地方，里面很容易出現(xiàn)內(nèi)存泄漏的代碼。 所謂 Date-prefetch 就是自定義實(shí)現(xiàn)的，在SSR處提前獲取第三方數(shù)據(jù)，用于繪制的過(guò)程。

Global Mixin 處

這個(gè)內(nèi)存泄漏的點(diǎn)想必大家都已經(jīng)熟知，作者也在github上詳細(xì)闡述過(guò)：GitHub issue

簡(jiǎn)單來(lái)說(shuō)，就是 global mixin 會(huì)給每個(gè) Vue 實(shí)例一個(gè)拷貝，而不是引用。

內(nèi)存泄漏的例子

以上列舉了一些可能出現(xiàn)內(nèi)存泄漏的地方，那么具體怎么樣的代碼才會(huì)引起內(nèi)存泄漏呢？引起代碼泄漏的例子網(wǎng)上有很多，我在這里想給大家介紹幾種常見(jiàn)的泄漏例子。

不小心造成的全局變量

function foo(arg) {
 bar = "this is a hidden global variable";
}

以上的代碼會(huì)順利運(yùn)行，但是因?yàn)椴恍⌒穆暶髁艘粋€(gè) bar 的變量。相當(dāng)于：

function foo(arg) {
 window.bar = "this is an explicit global variable";
}

生成了一個(gè)全局變量 window.bar

如果不手動(dòng)回收，這個(gè)全局變量會(huì)一直存在于內(nèi)存中，不會(huì)被CG回收。積少成多，最后造成內(nèi)存泄漏。

現(xiàn)在大家都是在各種模塊化（CommonJS/AMD/CMD/etc..）之后的環(huán)境下進(jìn)行開(kāi)發(fā)，這種全局變量的內(nèi)存泄漏的問(wèn)題基本上是被消除了。但是要提醒大家，由于JavaScript的各種特性，會(huì)有很多意想不到的狀況發(fā)生。當(dāng)摸不清頭腦的時(shí)候，可以嘗試從這些特性出發(fā)找到問(wèn)題。

被遺忘了的 Timer 或者 callback

請(qǐng)大家先看以下的例子

var someResource = getData();
setInterval(function() {
 var node = document.getElementById('Node');
 if(node) {
 // Do stuff with node and someResource.
 node.innerHTML = JSON.stringify(someResource));
 }
}, 1000);

乍一看沒(méi)啥問(wèn)題，之后如果 Node 節(jié)點(diǎn)從DOM上被移除，因?yàn)樯厦娴?callback 對(duì) Node 節(jié)點(diǎn)有引用，所以 Node 節(jié)點(diǎn)會(huì)一直常駐內(nèi)存，不會(huì)被CG回收。

要避免以上問(wèn)題，就要養(yǎng)成 removeEventListener 和 clearInterval 的習(xí)慣。

var someResource = getData();
var interval = setInterval(function() {
 var node = document.getElementById('Node');
 if(node) {
 // Do stuff with node and someResource.
 node.innerHTML = JSON.stringify(someResource));
 } else {
 // Remove Timer
 clearInterval(interval);
 }
}, 1000);

還比如：

var element = document.getElementById('button');

function onClick(event) {
 element.innerHtml = 'text';
}

element.addEventListener('click', onClick);
// Do stuff
element.removeEventListener('click', onClick);
element.parentNode.removeChild(element);
// Now when element goes out of scope,
// both element and onClick will be collected even in old browsers that don't
// handle cycles well.

在 addEventListener 之后已經(jīng)要記得 removeEventListener

閉包

閉包造成內(nèi)存泄漏的情況比較復(fù)雜，而且較難查找。限于本文主旨，不做原理說(shuō)明。

總結(jié)

個(gè)人認(rèn)為 VueJS SSR 后端繪制內(nèi)存泄漏造成影響要比普通的 VueJS 前端內(nèi)存泄漏造成的影響要更大。

前端內(nèi)存泄漏的影響，都是發(fā)生在客戶機(jī)器上，而且基本上現(xiàn)代瀏覽器也會(huì)做好保護(hù)機(jī)制，一般自行刷新之后都會(huì)解決。但是，一旦后端繪制內(nèi)存泄漏造成宕機(jī)之后，整個(gè)服務(wù)器都會(huì)受影響，危險(xiǎn)性更大，搞不好年終獎(jiǎng)就沒(méi)了。

前端工程師一般都是關(guān)注于瀏覽器端表現(xiàn)，在開(kāi)發(fā)過(guò)程中的內(nèi)存泄漏問(wèn)題不太在意也不太容易被發(fā)現(xiàn)。一般都是在項(xiàng)目上線一段時(shí)間之后，才發(fā)現(xiàn)內(nèi)存泄漏的情況。那個(gè)時(shí)候再去著手，可能會(huì)有些無(wú)從下手或者手忙腳亂。

那么，就讓我們?cè)陂_(kāi)發(fā)的時(shí)候開(kāi)始關(guān)注內(nèi)存泄漏問(wèn)題，將 VueJS SSR 后端繪制內(nèi)存泄漏問(wèn)題扼殺于襁褓之中。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論