javascript的垃圾回收机制与内存管理

谁借莪１个温暖的怀抱￠ 2022-05-28 04:42 134阅读 0赞

> 文章是本人大三期间的学习笔记，一些论断取自书籍和网上博客，碍于当时的技术水平有一些写得不够好的地方，可以在评论处理智讨论~

原文转自：[你不知道的JavaScript–Item28 垃圾回收机制与内存管理][JavaScript_Item28]

#### 垃圾回收机制—GC ####

--------------------

Javascript具有`自动垃圾回收机制(GC:Garbage Collecation)`，也就是说，执行环境会负责管理代码执行过程中使用的内存。

原理：\*\*垃圾收集器会定期（周期性）\*\*找出那些不在继续使用的变量，然后释放其内存。

JavaScript垃圾回收的机制很简单：找出不再使用的变量，然后释放掉其占用的内存，但是这个过程不是实时的，因为其开销比较大，所以**垃圾回收器会按照固定的时间间隔周期性的执行**。

不再使用的变量也就是生命周期结束的变量，当然只可能是局部变量，全局变量的生命周期直至浏览器卸载页面才会结束。局部变量只在函数的执行过程中存在，而在这个过程中会为局部变量在栈或堆上分配相应的空间，以存储它们的值，然后在函数中使用这些变量，直至函数结束，而闭包中由于内部函数的原因，外部函数并不能算是结束。

还是上代码说明吧：

我们来看代码是如何执行的。首先定义了两个 function，分别叫做 `fn1` 和 `fn2` ，当 `fn1` 被调用时，进入 `fn1` 的环境，会开辟一块内存存放对象 `{name: 'zwkkkk1', age: 21}` ，而当调用结束后，出了 `fn1` 的环境，那么该块内存会被 JavaScript 引擎中的垃圾回收器自动释放；在 `fn2` 被调用的过程中，返回的对象被全局变量 b 所指向，所以该块内存并不会被释放。

这里问题就出现了：到底哪个变量是没有用的？所以垃圾收集器必须跟踪到底哪个变量没用，对于不再有用的变量打上标记，以备将来收回其内存。用于标记的无用变量的策略可能因实现而有所区别，通常情况下有两种实现方式：标记清除和引用计数。引用计数不太常用，标记清除较为常用。

#### 标记清除 ####

--------------------

js中最常用的垃圾回收方式就是`标记清除`。当变量进入环境时，例如，**在函数中声明一个变量，就将这个变量标记为“进入环境”**。从逻辑上讲，永远不能释放进入环境的变量所占用的内存，因为只要执行流进入相应的环境，就可能会用到它们。而**当变量离开环境时，则将其标记为“离开环境”**。

function test(){
    	var a = 10 ; //被标记 ，a进入环境 
    	var b = 20 ; //被标记 ，b进入环境
    }
    test(); //执行完毕 之后 a、b又被标离开环境，被回收。

垃圾回收器在运行的时候会给存储在内存中的所有变量都加上标记（当然，可以使用任何标记方式）。然后，它会去掉环境中的变量以及被环境中的变量引用的变量的标记（闭包）。而在此之后再被加上标记的变量将被视为准备删除的变量，原因是环境中的变量已经无法访问到这些变量了。最后，垃圾回收器完成内存清除工作，销毁那些带标记的值并回收它们所占用的内存空间。

> 到目前为止，IE、Firefox、Opera、Chrome、Safari的js实现使用的都是标记清除的垃圾回收策略或类似的策略，只不过垃圾收集的时间间隔互不相同。

#### 引用计数 ####

--------------------

**`引用计数`的含义是跟踪记录每个值被引用的次数**。当声明了一个变量并将一个引用类型值赋给该变量时，则这个值的引用次数就是 1。如果同一个值又被赋给另一个变量，则该值的引用次数加1。相反，如果包含对这个值引用的变量又取得了另外一个值，则这个值的引用次数减 1。当这个值的引用次数变成 0 时，则说明没有办法再访问这个值了，因而就可以将其占用的内存空间回收回来。这样，当垃圾回收器下次再运行时，它就会释放那些引用次数为 0 的值所占用的内存。

Netscape Navigator3是最早使用引用计数策略的浏览器，但很快它就遇到一个严重的问题：`循环引用`。**循环引用指的是对象 A 中包含一个指向对象 B 的指针，而对象 B 中也包含一个指向对象 A 的引用**。

function fn() {
    	var a = {};
    	var b = {};
    	a.pro = b;
    	b.pro = a;
    }
     
    fn();

以上代码 a 和 b 的引用次数都是 2，fn() 执行完毕后，两个对象都已经离开环境，在标记清除方式下是没有问题的，但是在引用计数策略下，因为 a 和 b 的引用次数不为0，所以不会被垃圾回收器回收内存，如果 fn 函数被大量调用，就会造成内存泄露。在 IE7 与 IE8 上，内存直线上升。

我们知道，IE 中有一部分对象并不是原生 js 对象。例如，其内存泄露 DOM 和 BOM 中的对象就是使用 C++ 以 `COM 对象`的形式实现的，而 **COM 对象的垃圾回收机制采用的就是引用计数策略**。因此，即使 IE 的 js 引擎采用标记清除策略来实现，但 js 访问的 COM 对象依然是基于引用计数策略的。换句话说，**只要在 IE 中涉及 COM 对象，就会存在循环引用的问题**。

var element = document.getElementById("some_element");
    var myObject = new Object();
    myObject.e = element;
    element.o = myObject;

这个例子在一个 DOM 元素（element)与一个原生 js 对象（myObject) 之间创建了循环引用。其中，变量 myObject 有一个名为 element 的属性指向 element 对象；而变量 element 也有一个属性名为 o 回指 myObject。由于存在这个循环引用，即使例子中的 DOM 从页面中移除，它也永远不会被回收。

看上面的例子，有同学会觉得太弱了，谁会做这样无聊的事情，其实我们是不是就在做

window.onload=function outerFunction(){
    	var obj = document.getElementById("element");
    	obj.onclick = function innerFunction(){};
    };

这段代码看起来没什么问题，但是 obj 引用了 `document.getElementById(“element”)`，而 `document.getElementById(“element”)` 的 onclick 方法会引用外部环境中的变量，自然也包括obj，是不是很隐蔽啊。

#### 解决办法 ####

--------------------

最简单的方式就是自己手工解除循环引用，比如刚才的函数可以这样

myObject.element = null;
    element.o = null;

window.onload=function outerFunction(){
    	var obj = document.getElementById("element");
    	obj.onclick=function innerFunction(){};
    	obj=null;
    };

**将变量设置为 `null` 意味着切断变量与它此前引用的值之间的连接**。当垃圾回收器下次运行时，就会删除这些值并回收它们占用的内存。

要注意的是，**IE9+ 并不存在循环引用导致 Dom 内存泄露问题**，可能是微软做了优化，或者 Dom 的回收方式已经改变。

#### 内存管理 ####

--------------------

##### 1、什么时候触发垃圾回收？ #####

垃圾回收器周期性运行，如果分配的内存非常多，那么回收工作也会很艰巨，确定垃圾回收时间间隔就变成了一个值得思考的问题。**IE6 的垃圾回收是根据内存分配量运行的**，当环境中存在256个变量、4096个对象、64k的字符串任意一种情况的时候就会触发垃圾回收器工作，看起来很科学，不用按一段时间就调用一次，有时候会没必要，这样按需调用不是很好吗？但是如果环境中就是有这么多变量等一直存在，现在脚本如此复杂，很正常，那么结果就是垃圾回收器一直在工作，这样浏览器就没法儿玩儿了。

微软在 IE7 中做了调整，**触发条件不再是固定的，而是动态修改的**，初始值和 IE6 相同，如果垃圾回收器回收的内存分配量低于程序占用内存的 15%，说明大部分内存不可被回收，设的垃圾回收触发条件过于敏感，这时候把临界条件翻倍，如果回收的内存高于 85%，说明大部分内存早就该清理了，这时候把触发条件置回。这样就使垃圾回收工作智能了很多。

##### 2、合理的GC方案 #####

1）、JavaScript 引擎基础 GC 方案是（simple GC）：`mark and sweep`（标记清除），即：  
  （1）遍历所有可访问的对象。  
  （2）回收已不可访问的对象。

2）、GC的缺陷

和其他语言一样，JavaScript 的 GC 策略也无法避免一个问题：GC 时，停止响应其他操作，这是为了安全考虑。而 JavaScript 的 GC 在 `100ms` 甚至以上，对一般的应用还好，但对于 JS 游戏，动画对连贯性要求比较高的应用，就麻烦了。这就是新引擎需要优化的点：避免 GC 造成的长时间停止响应。

3）、GC优化策略

David大叔主要介绍了2个优化方案，而这也是最主要的2个优化方案了：

（1）分代回收（Generation GC）  
  这个和 Java 回收策略思想是一致的。目的是通过区分“临时”与“持久”对象；**多回收`“临时对象”区（young generation）`，少回收`“持久对象”区（tenured generation）`**，减少每次需遍历的对象，从而减少每次 GC 的耗时。如图：

![这里写图片描述][70]

这里需要补充的是：对于 `tenured generation` 对象，有额外的开销：把它从 `young generation` 迁移到 `tenured generation`，另外，如果被引用了，那引用的指向也需要修改。

（2）增量GC  
这个方案的思想很简单，就是“**每次处理一点，下次再处理一点，如此类推**”。如图：

![这里写图片描述][70 1]  
增量GC

这种方案，虽然耗时短，但中断较多，带来了上下文切换频繁的问题。因为每种方案都其适用场景和缺点，因此在实际应用中，会根据实际情况选择方案。

比如：低 (对象/s) 比率时，中断执行 GC 的频率，simple GC 更低些；如果大量对象都是长期“存活”，则分代处理优势也不大。

[JavaScript_Item28]: https://blog.csdn.net/i10630226/article/details/49684457
[70]: /images/20220528/1a9f6241a948423b859aaf4bb8bcc2a8.png
[70 1]: /images/20220528/a35c82a1d762414b8ef8c851e38420a4.png