JavaScript会在创建变量（对象，字符串等）时分配内存，并且在不再使用它们时“自动”释放内存，这个自动释放内存的过程称为垃圾回收。 因为自动垃圾回收机制的存在，让大多Javascript开发者感觉他们可以不关心内存管理，所以会在一些情况下导致内存泄漏。
内存生命周期
JS 环境中分配的内存有如下声明周期：
1.内存分配：当我们申明变量、函数、对象的时候，系统会自动为他们分配内存
2.内存使用：即读写内存，也就是使用变量、函数等
3.内存回收：使用完毕，由垃圾回收机制自动回收不再使用的内存
垃圾回收机制
原理：
垃圾收集器会按照固定的时间间隔， 周期性的找出不再继续使用的变量，然后释放其占用的内存 。
什么叫不再继续使用的变量？
不再使用的变量也就是生命周期结束的变量，是局部变量，局部变量只在函数的执行过程中存在，当函数运行结束，没有其他引用(闭包)，那么该变量会被标记回收。
全局变量的生命周期直至浏览器卸载页面才会结束，也就是说 全局变量不会被当成垃圾回收 。
标记清除：当前采用的垃圾收集策略
工作原理：
当变量进入环境时(例如在函数中声明一个变量)，将这个变量标记为“进入环境”，当变量离开环境时，则将其标记为“离开环境”。标记“离开环境”的就回收内存。
工作流程：
1.垃圾收集器会在运行的时候会给存储在内存中的 所有变量都加上标记 。
2.去掉环境中的变量以及被环境中的变量引用的变量的标记。
3.那些还存在标记的变量被视为准备删除的变量。
4.最后垃圾收集器会执行最后一步内存清除的工作，销毁那些带标记的值并回收它们所占用的内存空间。
到2008年为止,IE、Chorme、Fireofx、Safari、Opera 都使用标记清除式的垃圾收集策略 ，只不过垃圾收集的时间间隔互有不同。
引用计数：被废弃的垃圾收集策
循环引用：跟踪记录每个值被引用的技术
在老版本的浏览器中(对，又是IE)，IE9以下BOM和DOM对象就是使用C++以COM对象的形式实现的。
COM的垃圾收集机制采用的就是引用计数策略，这种机制在出现循环引用的时候永远都释放不掉内存。
var element = document.getElementById('something');
var myObject = new Object();
myObject.element = element; // element属性指向dom
element.someThing = myObject; // someThing回指myObject
出现循环引用(两个对象一直互相包含 一直存在计数)。
解决方式是，当我们不使用它们的时候，手动切断链接：
myObject.element = null;
element.someThing = null;
淘汰：
IE9把BOM和DOM对象转为了真正的js对象，避免了使用这种垃圾收集策略，消除了IE9以下常见的内存泄漏的主要原因。
IE7以下有一个声明狼藉的性能问题，大家了解一下：
1.256个变量，4096个对象(或数组)字面或者64KB的字符串，达到任何一个临界值会触发垃圾收集器运行。
2.如果一个js脚本的生命周期一直保有那么多变量，垃圾收集器会一直频繁的运行，引发严重的性能问题。
IE7已修复这个问题。
哪些情况会引起内存泄漏？
虽然有垃圾回收机制，但我们在编写代码的时候，有些情况还是会造成内存泄漏，了解这些情况，并在编写程序的时候，注意避免，我们的程序会更具健壮性。
意外的全局变量：
上文我们提到了 全局变量不会被当成垃圾回收 ，我们在编码中有时会出现下面这种情况：
function foo() {
this.bar2 = '默认绑定this指向全局' // 全局变量=> window.bar2
bar = '全局变量'; // 没有声明变量 实际上是全局变量=>window.bar
}
foo();
当我们使用 默认绑定，this会指向全局， this.something 也会创建一个全局变量，这一点可能很多人没有注意到。
解决方法：在函数内使用严格模式or细心一点
function foo() {
"use strict";
this.bar2 = "严格模式下this指向undefined";
bar = "报错";
}
foo();
当然我们也可以 手动释放全局变量的内存 ：
window.bar = undefined
delete window.bar2
被遗忘的定时器和回调函数
当 不需要 setInterval 或者 setTimeout 时， 定时器没有被clear ，定时器的 回调函数以及内部依赖的变量都不能被回收 ，造成内存泄漏。
var someResource = getData();
setInterval(function() {
var node = document.getElementById('Node');
if(node) {
node.innerHTML = JSON.stringify(someResource));
// 定时器也没有清除
}
// node、someResource 存储了大量数据 无法回收
}, 1000);
解决方法： 在定时器完成工作的时候，手动清除定时器。
闭包：
闭包可以维持函数内局部变量，使其得不到释放，造成内存泄漏。
function bindEvent() {
var obj = document.createElement("XXX");
var unused = function () {
console.log(obj,'闭包内引用obj obj不会被释放');
};
// obj = null;
}
解决方法：手动解除引用， obj = null 。
循环引用问题
就是IE9以下的循环引用问题，上文讲过了。
没有清理DOM元素引用：
var refA = document.getElementById('refA');
document.body.removeChild(refA); // dom删除了
console.log(refA, "refA"); // 但是还存在引用 能console出整个div 没有被回收
解决办法：refA = null;
console保存大量数据在内存中。
过多的console，比如定时器的console会导致浏览器卡死。
解决：合理利用console，线上项目尽量少的使用console，当然如果你要发招聘，除外。
如何避免内存泄漏：
记住一个原则：不用的东西，及时归还，毕竟你是’借的’嘛。
- 减少不必要的全局变量，使用严格模式避免意外创建全局变量。
- 在你使用完数据后，及时解除引用(闭包中的变量，dom引用，定时器清除)。
- 组织好你的逻辑，避免死循环等造成浏览器卡顿，崩溃的问题。
关于内存泄漏：
- 即使是1byte的内存，也叫内存泄漏，并不一定是导致浏览器崩溃、卡顿才能叫做内存泄漏。
- 一般是堆区内存泄漏，栈区不会泄漏。
基本类型的值存在内存中，被保存在栈内存中，引用类型的值是对象，保存在堆内存中。所以 对象、数组之类的，才会发生内存泄漏 。
内存泄漏的识别
如果连续五次垃圾回收之后，内存占用一次比一次大，就有内存泄漏。 这就要求实时查看内存的占用情况。
在 Chrome 浏览器中，我们可以这样查看内存占用情况
打开开发者工具，选择 Performance 面板
在顶部勾选 Memory
点击左上角的 record 按钮
在页面上进行各种操作，模拟用户的使用情况
一段时间后，点击对话框的 stop 按钮，面板上就会显示这段时间的内存占用情况
我们有两种方式来判定当前是否有内存泄漏：
多次快照后，比较每次快照中内存的占用情况，如果呈上升趋势，那么可以认为存在内存泄漏
某次快照后，看当前内存占用的趋势图，如果走势不平稳，呈上升趋势，那么可以认为存在内存泄漏
结语
了解了内存泄漏的原因以及出现的情况，那么我们在编码过程中只要多加注意，就不会发生非常严重的内存泄漏问题。
(网络资源整理而来)
网友评论