内存生命周期：
程序的运行需要 内存 ，只要程序提出要求，操作系统或者运行是就必须供给内存。
对于持续运行的服务进程，必须及时释放内存，否则，内存占用越来越高，轻则影响系统性能，重则导致进程崩溃。
内存泄露案例： 全局变量、未销毁的定时器和回调函数（ setInterval ）、闭包（外部函数的变量被引用，得不到释放）、DOM 引用（移除了元素，但是仍然有对 元素的引用）
用于标识无用变量的方式有两种：标记清除法和引用计数法。
当变量进入环境时，这个变量标记为“进入环境”；而当变量离开环境时，则将其标记为“离开环境”。
可使用一个“进入环境”的变量列表及一个“离开环境”的变量列表来跟踪变量的变化，也能够翻转某个特殊的位来记录一个变量什么时候进入环境及离开环境。
当声明了一个变量并将一个引用类型值赋给该变量时，则该值的引用次数就是1；若是同一个值又被赋给另外一个变量，则该值的引用次数加1；若是包含对该值引用的变量又取得了另一个值，则该值的引用次数减1。当该值的引用次数变为0时，则能够回收其占用的内存空间。 当垃圾回收器下一次运行时，就会释放那些引用次数为0的值所占用的内存。
怎样可以观察到内存泄漏呢？
经验法则 ：如果连续五次垃圾回收之后，内存占用一次比一次大，就有内存泄漏。这就要求实时查看内存占用。
前面说过，及时清除引用非常重要。但是，你不可能记得那么多，有时候一疏忽就忘了，所以才有那么多内存泄漏。
在新建引用的时候就声明，哪些引用必须手动清除，哪些引用可以忽略不计，当其他引用消失以后，垃圾回收机制就可以释放内存。 这样就能大大减轻程序员的负担，你只要清除主要引用就可以了。
在Node中如果通过JavaScript使用内存操作时会发现实际只能使用部分内存(64位系统下约为1.4G，32位系统下约为0.7G),这种限制对于其他的服务端开发语言来说基本上都是不存在的。
而问题的原因在于Node是基于V8构建，所以在Node中使用对象都是通过V8自己的方式进行分配和管理。
而其内存管理机制在浏览器的场景下问题不大，但是对于Node，却使得Node有了这般限制。
老生代中用标记 - 清除（Mark-Sweep）的算法来处理。
首先是标记过程阶段，标记阶段就是从一组根元素开始，递归遍历这组根元素(遍历调用栈)，在这个遍历过程中，能到达的元素称为活动对象,没有到达的元素就可以判断为垃圾数据.然后在遍历过程中标记，标记完成后就进行清除过程。它和副垃圾回收器的垃圾清除过程完全不同，这个的清除过程是删除标记数据。
清除算法后，会产生大量不连续的内存碎片。而碎片过多会导致大对象无法分配到足够的连续内存，于是又产生了标记 - 整理（Mark-Compact）算法，这个标记过程仍然与标记 - 清除算法里的是一样的，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，从而让存活对象占用连续的内存块。
内存泄漏的几种情况 ：
1.页面中元素被移除或替换时，元素绑定的时间仍然存在
解决： 在onclick事件中将oButton.onclick=null手动释放
2.两个DOM节点或ActiveX对象相互引用，在IE中垃圾回收系统不会发现他们之间循环关系与系统中其他对象是隔离的并释放他们，最终他们将被保留在内存中，直到浏览器关闭
3.闭包也会引起内存泄漏
解决 在确定某个变量不会再次被引用。手动释放其内存，即将此变量设置为null
js中垃圾回收机制有两种：
1.标记清除：最常用！
垃圾收集器会在运行的时候给存储在内存的所有变量加上一个标记，然后会去掉环境中的变量以及环境中被引用的变量，在此之后再被加上标记的变量就是为准备删除的变量
2.引用计数
跟踪记录每一个个值的被引用次数，当一个值引用次数为0时，回收
但是这种方法有一个很严重的问题！！ 循环引用
循环引用就是对象A中包含一个指向对象B的指针，而对象B中又包含一个指向A的指针，他们的引用次数永远不会是0
