垃圾回收
目录
JavaScript 垃圾回收的基本思路
JavaScript 是使用垃圾回收的语言，即执行环境负责在代码执行时管理内存。
JavaScript 通过自动内存管理实现内存分配和闲置资源回收，基本思路为：确定哪个变量不再使用，然后释放它占用的内存。
垃圾回收的过程是周期性的，垃圾回收程序每隔一定时间（或者说在代码执行过程中执行某个预定的收集时间）就会自动运行。
垃圾回收过程是一个近似且不完美的方案，因为某块内存是否还有用，属于不可判定问题，意味着依靠算法无法解决。
函数中局部变量的不可判定问题示例
以函数中局部变量的正常生命周期为例。函数中的局部变量会在函数执行时存在。栈（或堆）内存会分配空间以保存相应的值。
函数在内部使用局部变量，在函数退出函数执行栈时，不再需要局部变量，此时局部变量占用的内存可以释放，供后续代码继续使用。
上述情况对于局部变量的内存管理十分清晰简单，但并不是所有时候都如此明显。
垃圾回收程序必须跟踪记录哪个变量还会使用，以及哪个变量不会再使用，以便回收内存。
在浏览器的发展史上用到过两种主要的标记未使用变量的实现方式：标记清理和引用计数。
标记清理
JavaScript 最常用的垃圾回收策略就是标记清理（mark-end-sweep）。
当变量进入执行上下文中，比如在函数内部声明一个变量时，这个变量会被加上存在于上下文的标记。而在上下文中的变量，逻辑上讲，永远不应该释放它们所占用的内存，因为只要这个上下文中的代码还在运行，就有可能使用到它们。当然，当变量离开执行上下文时，也会被加上离开上下文的标记。
变量添加标记的方式
当变量进入上下文时，反转某一位；
维护“在上下文中”和“不在上下文中”两个变量列表，可以把变量从一个列表转移到另一个列表。
当然，标记过程的实现并不重要，关键在于策略。
标记清理的策略
垃圾回收程序运行时，会标记内存中存储的所有变量（标记方式随便）。然后，它会将所有在上下文中的变量，以及被在上下文中的变量引用的变量的标记去掉。在此之后再被加上标记的变量就是待删除变量，原因：任何在上下文中的变量都不会访问它们（即变量不再被使用）。随后垃圾回收程序做一次内存清理，销毁带标记的所有值并收回它们的内存。
到 2008 年，IE、Firefox、Opera、Chrome 和 Safari 均在自己的 JavaScript 实现中采用标记清理（或其变体），只是在运行垃圾回收的频率上有所差异。
引用计数
引用计数（reference counting）垃圾回收策略并不常用。
思路为：对每个值都就它被引用的次数。声明变量并给它赋一个引用值，该值的引用数为 1。如果同一个又被赋值给另一个变量，那么引用数加 1。类似地，如果保存对该值引用的变量被其他值覆盖，那么引用数减 1。当一个值的引用数为 0 时，就说明没有变量会访问该值，因此可以安全地收回其内存。垃圾回收程序下次运行时，就会释放引用数为 0 的值的内存。
引用计数的问题 - 循环引用
所谓循环引用，即对象 A 有一个指针指向对象 B，而对象 B 也引用了对象 A。
function problem() {
let objectA = new Object();
let objectB = new Object();
objectA.someOtherObject = objectB;
objectB.anotherObject = objectA;
}
在上述例子中，objectA 和 objectB 通过各自的属性相互引用，意味着它们各自的引用数为 2。
在标记清理策略下，在函数结束后，两个对象都不存在作用域中，其占用内存会被清理。
而在引用计数策略下，由于它们互相引用，其引用数永远不会变为 0，故而在函数结束后仍会存在。如果函数被多次调用，则会导致大量内存永远不会被释放。
性能
垃圾回收程序会周期性运行，如果内存中分配了很多变量，则可能造成性能损失，因此垃圾回收的时间调用很重要。
现代垃圾回收程序会基于对 JavaScript 运行时环境的探测来决定何时运行。探测机制因引擎而异，但基本上都是根据已分配对象的大小和属性进行判断。
内存管理
出于安全考虑，避免运行大量 JavaScript 代码的的网页耗尽系统内存而导致操作系统崩溃。故而分配给浏览器的内存通常比分配给桌面软件的内存要少很多，分配给移动浏览器的内存更少。
上述内存限制不仅影响变量分配，也影响调用栈以及能够同时在一个线程中执行的语句数量。
将内存占用量保持在一个较小的值可以让页面性能更好。优化内存占用的最佳手段就是保证在执行代码时只保存必要的数据。如果数据不再必要，那么把它设置为 null，从而释放其引用，即解除引用。
上述建议最适合全局变量和全局对象的属性，因为局部变量在超出其作用域后会被自动接触引用。
function createPerson(name) {
let localPerson = new Object();
localPerson.name = name;
return localPerson;
}
let globalPerson = createPerson("huaqi");
// ...
// 解除 globalPerson 对值的引用
globalPerson = null;
在上述代码中，变量 localPerson 会在 createPerson() 函数执行完毕后超出执行上下文然后自动被解除引用，不需要显式处理。但对于全局变量 globalPerson，应该在不需要时手动解除其引用。
注：解除对一个值的引用并不会自动导致相关内存被回收。解除引用的关键在于确保相关的值已经不在当前上下文中，使其在下一次垃圾回收时被回收。
通过 const 和 let 声明提升性能
关键字 const 和 let 不仅有助于改善代码风格，同样有助于改进垃圾回收的过程。
因为 const 和 let 都使用块作用域（非函数作用域），相比于使用 var，在块作用域比函数作用域更早终止的情况下，它们会更早地让垃圾回收程序介入，尽早回收应该回收的内存。
隐藏类和删除操作
根据 JavaScript 所在的运行环境，有时候需要根据浏览器使用 JavaScript 引擎以采取不同的性能优化策略。
V8 JavsScript 引擎会将解释后的 JavaScript 代码编译为实际的机器码时会利用隐藏类。
代码运行期间，V8 会将创建的对象与隐藏类进行关联，以跟踪它们的属性特性。能够共享相同隐藏类的对象的代码其性能会更好，V8 会针对这种情况进行优化，但不一定总能做到。
function Article() {
this.title = "huaqi";
}
let a1 = new Article();
let a2 = new Article();
V8 会在后台进行配置，使上述两个类实例共享相同的隐藏类，因为这两个实例共享同一个构造函数和原型。
若在上述代码下添加：
a2.author = "huaqi";
此时，V8 在编译代码后，两个 Article 实例会对应两个不同的隐藏类。根据这种操作的频率和隐藏类的大小，这有可能对性能产生明显影响。
上述问题的解决方案：避免 JavaScript 进行先创建再补充式（ready-fire-aim）的动态属性赋值，在构造函数中一次声明所有需要的属性。
funciton Article(opt_author) {
this.title = "huaqi";
this.author = opt_author;
}
let a1 = new Article();
let a2 = new Article("huaqi");
上述代码中的两个 Article 实例基本上一致（不考虑 hasOwnProperty 的返回值），共享一个隐藏类，从而带来潜在的性能提升。但是，使用 delete 关键字会导致再生成相同的隐藏类片段。
funciton Article(opt_author) {
this.title = "huaqi";
this.author = opt_author;
}
let a1 = new Article();
let a2 = new Article("huaqi");
delete a1.author;
V8 解释完上述代码后，尽管两个实例使用了同一个构造函数，它们也不再共享一个隐藏类。动态删除属性与动态添加属性导致的后果一样。
最佳实践是将不想要的属性值赋值为 null。这样可以保持隐藏类不变和继续共享，同时也能达到删除引用值供垃圾回收程序回收内存的结果。
funciton Article(opt_author) {
this.title = "huaqi";
this.author = opt_author;
}
let a1 = new Article();
let a2 = new Article("huaqi");
a1.author = null;
内存泄漏
不好的 JavaScript 代码可能出现难以察觉且有害的内存泄露问题。
在内存有限的设备上或在函数会被调用很多次的情况下，内存泄露可能是个大问题，JavaScript 中的内存泄露大部分是由于不合理的引用导致的。
意外声明全局变量
意外声明全局变量是最常见，但也最容易修复的内存泄露问题
function setName() {
name = "huaqi";
}
针对上述代码，解释器会将变量 name 作为全局对象 window 的属性进行创建（window.name = “huaqi”）。而在 window 对象上创建的属性，只要 window 本身不被清理就不会消失。
解决上述问题，只需要在变量声明前添加 var、let 或 const 关键字即可，这样变量就会在函数执行完毕后离开作用域，进而被清除。
定时器引用外部变量
定时器也可能会悄悄地导致内存泄露，下述代码中，定时器的回调通过闭包引用了外部变量，只要定时器一直运行，回调函数中引用的 name 就会一直占用内存。因而垃圾回收程序就不会清理外部变量 name。
let name = "huaqi";
setInterval(() => {
console.log(name);
}, 100);
闭包导致内存泄露
let outer = function() {
let name = "huaqi";
return function() {
return name;
}
}
调用函数 outer() 会导致分配给 name 的内存被泄露。上述代码执行后会创建一个内部闭包，只要返回的函数一直存在就不能清理 name，因为闭包一直在引用它。
静态分配与对象池
为了提升 JavaScript 性能，最后要考虑的一点往往就是压榨浏览器。此时的一个关键问题就是如何减少浏览器执行垃圾回收的次数。
开发者无法直接控制何时开始收集垃圾，但可以间接控制触发垃圾回收的条件。理论上，如果能够合理使用分配的内存，同时避免多余的垃圾回收，那就可以保住因释放内存而损失的性能。
降低对象更替的速度
浏览器决定何时运行垃圾回收程序的一个标准就是对象更替的速度。
如果有很多对象被初始化，然后又一起超出作用域，那么浏览器就会采用更激进的方式调度垃圾回收程序运行，这样就会影响性能。
function addVector(a, b) {
let resultant = new Vector();
resultant.x = a.x + b.x;
resultant.y = a.y + b.y;
return resultant;
}
调用上述 addVector() 函数时，会在堆上创建一个新对象，然后修改它，最后再将其返回给调用者。
如果这个矢量对象的生命周期很短，那么它会很快失去所有对它的引用，成为可以被回收的值。
假如 addVector() 函数频繁地被调用，那么垃圾回收调度程序就会发现这里的对象更替的速度很快，从而会更频繁地安排垃圾回收。
上述问题的解决方案：不再动态创建矢量对象，使用已有的矢量对象。
function addVector(a, b, resultant) {
resultant.x = a.x + b.x;
resultant.y = a.y + b.y;
return resultant;
}
当然，上述代码需要在其他地方实例化矢量类 Vector。
一个策略是使用对象池。在初始化的某一时刻，可以创建一个对象池，拥有管理一组可回收的对象。应用程序可以向这个对象池请求一个对象、设置其属性、使用对象，然后在操作完成后再把它还给对象池。
由于对象池的存在，没有进行频繁的对象初始化，垃圾回收探测不会发现有对象更替，因此垃圾回收程序就不会那么频繁地运行。
对象池的伪实现：
// vectorPool 是已有的对象池
let v1 = vectorPool.allocate();
let v2 = vectorPool.allocate();
let v3 = vectorPool.allocate();
v1.x = 10;
v1.y = 5;
v2.x = -3;
v2.y = -6;
addVector(v1, v2, v3);
console.log([v3.x, v3.y]); // [7, -1]
vectorPool.free(v1);
vectorPool.free(v2);
vectorPool.free(v3);
// 如果对象有属性引用了其他对象
// 则需要将这些属性设置为 null
v1 = null;
v2 = null;
v3 = null;
如果对象池只按需分配矢量（在对象不存在时创建新对象，在对象存在时复用已存在对象），那么这个实现本质是一种贪婪算法，有单调增长但为静态的内存。这个对象池必须使用某种结构维护所有对象，数组是比较好的选择。使用数组实现，必须留意不要招致额外的垃圾回收。
let vectorList = new Array(100);
let vector = new Vector();
vectorList.push(vector);
由于 Javascript 数组的大小是动态可变的，在执行 vectorList.push(vector) 代码时，引擎会删除大小为 100 的数组，再创建新的大小为 200 的数组。
当垃圾回收程序检测到上述的删除操作，可能会很快地进行一次垃圾回收。所以，要避免上述这种动态分配操作，可以在初始化时就创建一个大小够用的数组，从而避免上述先删除原有数组，再创建新的数组的操作。
静态属性分配优化是一种极端形式。如果应用程序被垃圾回收严重降低性能，可以利用其提升性能。但这种情况并不多见。大多数情况下，都属于过早优化。
1631
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
