Javascript垃圾回收机制(学习笔记)

时间:2024-01-01 20:40:21

1,javascript具有自动的垃圾回收机制,自动内存的分配和无用内存的回收都可以自动管理。垃圾回收器周期性的执行;

2,Javascript的垃圾回收策略分为:引用计数和标记清除;
2.1 标记清除:根据变量是否进入环境和离开环境,来判断此变量的标记,如果离开“环境”,则将其的标记更新为“离开环境”,等到下次垃圾回收器执行垃圾回收的时候,对这些已经打上“离开环境”标记的变量执行回收操作,回收其内存。(主流)
2.2 引用计数:跟踪变量被引用的次数,当申明一个变量并引用类型值赋给变量时,引用次数+1,每次把该变量赋值给另一个变量的时候,引用计数+1,以此类推;相反,如果包含对这个值引用的变量有获得另外一个值时,引用次数-1,以此类推,当该变量的引用计数等于0时,则说明该变量已经没有变量引用,垃圾回收器下次执行的时候,就会回收该变量,释放该变量所占的内存空间。(注意:引用计数存在一个严重的问题:循环引用。对象 A 中包含一个指向对象 B 的指针,而对象 B 中也包含一个指向对象 A 的引用。)
var objectA = new Object();
var objectB = new Object();
objectA.someOtherObject = objectB;
objectB.anotherObject = objectA;
IE 中有一部分对象并不是原生 JavaScript 对象。例如,其 BOM 和 DOM 中的对象就是使用 C++以 COM( Component Object Model,组件对象模型)对象的形式实现的,而 COM 对象的垃圾收集机制采用的就是引用计数策略。因此,即使 IE 的 JavaScript 引擎是使用标记清除策略来实现的,但JavaScript 访问的 COM 对象依然是基于引用计数策略的。换句话说,只要在 IE 中涉及 COM 对象,就会存在循环引用的问题。 IE9 把 BOM 和 DOM 对象都转换成了真正的 JavaScript 对象。这样,就避免了两种垃圾收集算法并存导致的问题,也消除了常见的内存泄漏现象。(节选于《Javascript高级程序设计》(第3版))
垃圾收集器是周期性运行的,而且如果为变量分配的内存数量很可观,那么回收工作量也是相当大的。在这种情况下,确定垃圾收集的时间间隔是一个非常重要的问题。说到垃圾收集器多长时间运行一次,不禁让人联想到 IE 因此而声名狼藉的性能问题。 IE 的垃圾收集器是根据内存分配量运行的,具体一点说就是 256 个变量、 4096 个对象(或数组)字面量和数组元素(slot)或者 64KB 的字符串。达到上述任何一个临界值,垃圾收集器就会运行。这种实现方式的问题在于,如果一个脚本中包含那么多变量,那么该脚本很可能会在其生命周期中一直保有那么多的变量。而这样一来,垃圾收集器就不得不频繁地运行。结果,由此引发的严重性能问题促使 IE7 重写了其垃圾收集例程。随着 IE7 的发布,其 JavaScript 引擎的垃圾收集例程改变了工作方式:触发垃圾收集的变量分配、字面量和(或)数组元素的临界值被调整为动态修正。 IE7 中的各项临界值在初始时与 IE6 相等。如果垃圾收集例程回收的内存分配量低于 15%,则变量、字面量和(或)数组元素的临界值就会加倍。如果例程回收了 85%的内存分配量,则将各种临界值重置回默认值。这一看似简单的调整,极大地提升了 IE在运行包含大量JavaScript 的页面时的性能。(节选于《Javascript高级程序设计》(第3版))
3,管理内存
Javascript分配给web浏览器的可用内存数量通常要比分配给桌面应用程序的少,这样做的目的主要是出于安全方面的考虑,目的是防止运行 JavaScript 的网页耗尽全部系统内存而导致系统崩溃。内存限制问题不仅会影响给变量分配内存,同时还会影响调用栈以及在一个线程中能够同时执行的语句数量。因此,确保占用最少的内存可以让页面获得更好的性能。而优化内存占用的最佳方式,就是为执行中的代码只保存必要的数据。一旦数据不再有用,最好通过将其值设置为 null 来释放其引用——这个做法叫做解除引用( dereferencing)。这一做法适用于大多数全局变量和全局对象的属性。局部变量会在

它们离开执行环境时自动被解除引用。解除引用的真正作用是让值脱离执行环境,以便垃圾收集器下次运行时将其回收。(节选于《Javascript高级程序设计》(第3版))