了解js的垃圾回收机制无论是对以后的面试还是深入js的开发都有很大的帮助。普通js的垃圾回收在开发过程中，我们创建的基本数据类型和引用数据类型需要开辟内存空间才能运行，否则会存在内存溢出、泄漏等风险。你需要知道的是：js中的内存管理对用户是不可见的，是自动执行的。重点：js引擎如何处理那些我们不再需要释放内存的数据类型。这就是js的垃圾回收机制。什么样的数据会被回收？简单的说，一个数据类型的声明期结束后，就会被回收，释放它的内存。全局变量的生命周期一直持续到会话关闭。局部变量的生命周期在函数执行后结束。经常提到的js垃圾回收的两种方法标记和清除。当一个变量被声明进入js的执行环境时，垃圾回收器将其标记为“进入环境”，并在变量结束其生命周期后将其标记为“离开环境”。标有“当前执行环境中的变量”的变量不会被清除，其他变量会被清除回收。它将删除环境中的变量和环境中变量引用的变量标签（闭包）。之后，剩余标记的变量被视为准备删除的变量。垃圾回收机制是按照一定周期运行的“根”的概念。另一种解释方式是解释“根”的概念https://segmentfault.com/a/11...低引用计数版本的IE使用这种方式，存在内存泄漏的风险。该机制是跟踪变量的引用次数：当声明一个变量并为该变量分配引用类型时，该值的引用次数增加1，当变量指向其他值时，该变量的引用次数引用数减1，当引用数为0时回收。这种方法之所以会造成内存泄漏，是因为它无法解决循环引用函数sample(){vara={};的问题。变量b={};a.prop=b;b.prop=a;}在这种情况下每次调用sample()函数时，a和b的引用计数都是2，会导致这部分内存永远释放不掉，即内存泄漏。低版本IE中的一些对象不是原生的JS对象。例如，其BOM和DOM中的对象使用C++以COM（ComponentObjectModel）对象的形式实现，COM对象的垃圾回收机制采用引用计数策略。因此，即使IE的js引擎是用标记清除实现的，js对BOM、DOM等COM对象的访问仍然是基于引用计数的策略，也就是说只要在IE中设计了COM对象，就会有是循环引用的问题。对于全局的或者一直存在于执行环境的变量，可以手动清空，需要的时候释放内存
