共计 5377 个字符,预计需要花费 14 分钟才能阅读完成。
本文首发于公众号:合乎预期的 CoyPan
写在后面
在所有的编程语言中,咱们申明一个变量时,须要零碎为咱们调配一块内存。当咱们不再须要这个变量时,须要将内存进行回收(这个过程称之为垃圾回收)。在 C 语言中,有 malloc 和 free 来帮助咱们进行内存治理。在 JS 中,开发者不须要手动进行内存治理,JS 引擎会为咱们主动做这些事件。然而,这并不意味着咱们在应用 JS 进行编码时,不须要关怀内存问题。
JS 中的内存调配与变量
内存申明周期如下:
- 调配你所须要的内存
- 应用调配到的内存(读、写)
- 不须要时将其开释
在 JS 中,这三步都是对开发者无感的,不须要咱们过多的关怀。
咱们须要留神的是,当咱们申明一个变量、失去一块内存时,须要正确区分一个变量到底是一个根本类型还是援用类型。
根本类型:String,Number,Boolean,Null,Undefined,Symbol
援用类型:Object,Array,Function
对于根本类型变量来说,零碎会为其调配一块内存,这块内存中保留的,就是变量的内容。
对于援用类型变量来说,其存储的只是一个地址而已,这个地址指向的内存块才是是变量的真正内容。援用变量的赋值,也只是把地址进行传递(复制)。举个例子:
// a 和 b 指向同一块内存
var a = [1,2,3];
var b = a;
a.push(4);
console.log(b); // [1,2,3,4]
还有一点须要留神,JS 中的函数传参,其实是按值传递(按援用传递)。举个例子:
// 函数 f 的入参,其实是把 a 的值复制了一份。留神 a 是一个援用类型变量,其保留的是一个指向内存块的一个地址。function f(obj) {obj.b = 1;}
var a = {a : 1};
f(a);
console.log(a); // {a: 1, b: 1}
在平时的开发中,齐全了解 JS 中变量的存储形式是非常重要的。对于我本人来说,尽量避免把援用类型变量到处传递,可能一不小心在某个中央批改了变量,另一个中央逻辑没有判断好,很容易出 Bug,特地是在我的项目复杂度较高,且多人开发时。这也是我比拟喜爱应用纯函数的起因。
另外,依据我之前的面试教训,有不少的小伙伴认为上面的代码会报错,这也是对 JS 中变量存储形式把握不熟导致的。
// const 申明一个不可扭转的变量。// a 存储的只是数组的内存地址而已,a.push 并不会扭转 a 的值。const a = [];
a.push('1');
console.log(a); // ['1']
JS 中的垃圾回收
垃圾回收算法次要依赖于援用的概念。在内存治理的环境中,一个对象如果有拜访另一个对象的权限(隐式或者显式),叫做一个对象援用另一个对象。例如,一个 Javascript 对象具备对它原型的援用(隐式援用)和对它属性的援用(显式援用)。
在这里,“对象”的概念不仅特指 JavaScript 对象,还包含函数作用域(或者全局词法作用域)。当变量不再须要时,JS 引擎会把变量占用的内存进行回收。然而怎么界定【变量不再须要】呢?次要有两种办法。
援用计数算法
把“对象是否不再须要”简化定义为“对象有没有其余对象援用到它”。如果没有援用指向该对象(零援用),对象将被垃圾回收机制回收。MDN 上的例子:
var o = {
a: {b:2}
};
// 两个对象被创立,一个作为另一个的属性被援用,另一个被调配给变量 o
// 很显然,没有一个能够被垃圾收集
var o2 = o; // o2 变量是第二个对“这个对象”的援用
o = 1; // 当初,“这个对象”只有一个 o2 变量的援用了,“这个对象”的原始援用 o 曾经没有
var oa = o2.a; // 援用“这个对象”的 a 属性
// 当初,“这个对象”有两个援用了,一个是 o2,一个是 oa
o2 = "yo"; // 尽管最后的对象当初曾经是零援用了,能够被垃圾回收了
// 然而它的属性 a 的对象还在被 oa 援用,所以还不能回收
oa = null; // a 属性的那个对象当初也是零援用了
// 它能够被垃圾回收了
这种办法有一个局限性,那就是无奈解决循环援用。在上面的例子中,两个对象被创立,并相互援用,造成了一个循环。它们被调用之后会来到函数作用域,所以它们曾经没有用了,能够被回收了。然而,援用计数算法思考到它们相互都有至多一次援用,所以它们不会被回收。
// 这种状况下,o 和 o2 都无奈被回收。function f(){var o = {};
var o2 = {};
o.a = o2; // o 援用 o2
o2.a = o; // o2 援用 o
return "azerty";
}
f();
标记 - 革除算法
这个算法假设设置一个叫做根(root)的对象(在 Javascript 里,根是全局对象)。垃圾回收器将定期从根开始,找所有从根开始援用的对象,而后找这些对象援用的对象……从根开始,垃圾回收器将找到所有能够取得的对象和收集所有不能取得的对象。
对于 JS 中的垃圾回收算法,网上曾经有很多的文章解说,这里不再进行赘述。
JS 中的内存泄露
只管 JS 为咱们主动解决内存的调配、回收问题,然而在某些特定的场景下,JS 的垃圾回收算法并不能帮咱们去除曾经不再应用的内存。这种【因为忽略或谬误造成程序未能开释曾经不再应用的内存】的景象,被称作内存泄露。
内存占用越来越高,轻则影响零碎性能,重则导致过程解体。
可能产生内存泄露的场景有不少,包含全局变量,DOM 事件,定时器等等。
上面是一段存在内存泄露的示例代码:
class Page1 extends React.Component {events= []
componentDidMount() {window.addEventListener('scroll', this.handleScroll.bind(this));
}
render() {
return <div>
<div><Link to={'/page2'}> 返回 Page2</Link></div>
<p>page1</p>
....
</div>
}
handleScroll(e) {this.events.push(e);
}
}
当咱们点击按钮跳转到 Page2 后,在 page2 不停进行滚动操作,咱们会发现内存占用一直的上涨:
产生这个内存泄露的起因是:咱们在 Page1 被 unmount 的时候,只管 Page1 被销毁了,然而 Page1 的滚动回调函数通过 eventListener 仍然可“触达”,所以不会被垃圾回收。进入 Page2 后,滚动事件的逻辑仍然失效,外部的变量无奈被 GC。如果用户在 Page2 进行长时间滑动等操作,页面会逐步变得卡顿。
上述的例子,在咱们开发的过程中,并不少见。不仅仅是事件绑定,也有可能是定时上报逻辑等等。如何解决呢?记得在 unmount 的时候,进行相应的勾销操作即可。
在平时的我的项目开发中,内存泄露还有很多其余的场景。浏览器页面还好,毕竟始终开着某个页面的用户不算太多,刷新就好。而 Node.js 产生内存泄露的结果就比较严重了,可能服务就间接解体了。把握 JS 的变量存储形式、内存管理机制,养成良好的编码习惯,能够帮忙咱们缩小内存泄露的产生。
JS 中的弱援用
后面咱们讲到了 JS 的垃圾回收机制,如果咱们持有对一个对象的 援用 ,那么这个对象就不会被垃圾回收。这里的援用,指的是 强援用。
在计算机程序设计中,还有一个 弱援用 的概念:一个对象若只被弱援用所援用,则被认为是不可拜访(或弱可拜访)的,并因而可能在任何时刻被回收。
在 JS 中,WeakMap 和 WeakSet 给咱们提供了弱援用的能力。
WeakMap、WeakSet
要说 WeakMap,先来说一说 Map。Map 对象保留键值对,并且可能记住键的原始插入程序。任何值(对象或者原始值) 都能够作为一个键或一个值。
Map 对对象是强援用:
const m = new Map();
let obj = {a: 1};
m.set(obj, 'a');
obj = null; // 将 obj 置为 null 并不会使 {a: 1} 被垃圾回收,因为还有 map 援用了 {a: 1}
WeakMap 是一组键 / 值对的汇合,其中的键是弱援用的。其键必须是对象,而值能够是任意的。WeakMap 是对对象的弱援用:
const wm = new WeakMap();
let obj = {b: 2};
wm.set(obj, '2');
obj = null; // 将 obj 置为 null 后,只管 wm 仍然援用了{b: 2},然而因为是弱援用,{b: 2} 会在某一时刻被 GC。
正因为这样的弱援用,WeakMap 的 key 是不可枚举的 (没有办法能给出所有的 key)。如果 key 是可枚举的话,其列表将会受垃圾回收机制的影响,从而失去不确定的后果。
WeakSet 能够视为 WeakMap 中所有值都是布尔值的一个特例,这里就不再赘述了。
JavaScript 的 WeakMap 并 不是真正意义上的弱援用:实际上,只有键依然存活,它就强援用其内容。WeakMap 仅在键被垃圾回收之后,才弱援用它的内容。这种关系更精确地称为 ephemeron。
WeakRef
WeakRef 是一个更高级的 API,它提供了真正的弱援用。咱们间接借助上文的内存泄露的例子来看一看 WeakRef 的成果:
import React from 'react';
import {Link} from 'react-router-dom';
// 应用 WeakRef 将回调函数“包裹”起来,造成对回调函数的弱援用。function addWeakListener(listener) {const weakRef = new WeakRef(listener);
const wrapper = e => {if (weakRef.deref()) {return weakRef.deref()(e);
}
}
window.addEventListener('scroll', wrapper);
}
class Page1 extends React.Component {events= []
componentDidMount() {addWeakListener(this.handleScroll.bind(this));
}
componentWillUnmount() {console.log(this.events);
}
render() {
return <div>
<div><Link to={'/page2'}> 返回 Page2</Link></div>
<p>page1</p>
....
</div>
}
handleScroll(e) {this.events.push(e);
}
}
export default Page1;
咱们再来看看点击按钮跳转到 page2 后的内存体现:
能够很直观的看到,在跳转到 page2 后,继续滚动一段时间后,内存安稳。这是因为随着 page1 被 unmount,真正的滚动回调函数(Page1 的 handleScroll 函数)被 GC 掉了。其外部的变量也最终被 GC。
但其实,这里还有一个问题,尽管咱们通过weakRef.deref()
拿不到 handleScroll 滚动回调函数了(已被 GC),然而咱们的包裹函数 wrapper 仍然会执行。因为咱们没有执行 removeEventListener。现实状况是:咱们心愿滚动监听函数也被勾销掉。
能够借助 FinalizationRegistry 来实现这个性能。看上面的示例代码:
// FinalizationRegistry 构造函数承受一个回调函数作为参数,返回一个示例。咱们把实例注册到某个对象上,当该对象被 GC 时,回调函数会触发。const gListenersRegistry = new FinalizationRegistry(({window, wrapper}) => {console.log('GC happen!!');
window.removeEventListener('scroll', wrapper);
});
function addWeakListener(listener) {const weakRef = new WeakRef(listener);
const wrapper = e => {console.log('scroll');
if (weakRef.deref()) {return weakRef.deref()(e);
}
}
// 新增这行代码,当 listener 被 GC 时,会触发回调函数。回调函数传参由咱们本人管制。gListenersRegistry.register(listener, { window, wrapper});
window.addEventListener('scroll', wrapper);
}
WeakRef 和 FinalizationRegistry 属于高级 Api,在 Chrome v84 和 Node.js 13.0.0 后开始反对。个别状况下不倡议应用。因为容易用错,导致更多的问题。
写在前面
本文从 JS 中的内存治理讲起,说到了 JS 中的弱援用。尽管 JS 引擎帮咱们解决了内存治理问题,然而咱们在业务开发中并不能齐全漠视内存问题,特地是在 Node.js 的开发中。
对于 V8 的内存策略的更多细节,能够移步我之前翻译的一篇文章:
V8 引擎的内存治理
参考资料:
1、https://www.youtube.com/watch…
2、https://www.infoq.cn/article/…*bbYg
3、https://developer.mozilla.org…