今天看到一篇关于js使用中内存泄露的文章，以及chrom浏览器查看内存泄漏的方法，决定留着。本文只截取了我认为比较重要的部分，喜欢原文的小伙伴，请点击文章下方的原文链接。
什么是内存泄露？内存泄露是指new了一块内存，但无法被释放或者被垃圾回收。new了一个对象之后，它申请占用了一块堆内存，当把这个对象指针置为null时或者离开作用域导致被销毁，那么这块内存没有人引用它了在JS里面就会被自动垃圾回收。但是如果这个对象指针没有被置为null，且代码里面没办法再获取到这个对象指针了，就会导致无法释放掉它指向的内存，也就是说发生了内存泄露。为什么代码里面会拿不到这个对象指针了呢，举一个例子：
// module date.js let date = null; export default { init () { date = new Date(); } } // main.js import date from 'date.js'; date.init();
在main.js初始化了date之后，date这个变量就一会直存在了，直到你把页面关了，因为date的引用是在另一个module里面，可以理解为模块就是一个闭包对外是不可见的。所以如果你是希望这个date对象一直存在、需要一直使用的话，那么没有问题，但是如果想用一次就不用了那就会有问题，这个对象一直在内存里面没有被释放就发生了内存泄露。
另一种比较隐蔽并且很常见的内存泄露是事件绑定，形成了一个闭包，导致一些变量一直存在。如下例子所示：
// 一个图片懒惰加载引擎示例 class ImageLazyLoader { constructor ($photoList) { $(window).on('scroll', () => { this.showImage($photoList); }); } showImage ($photoList) { $photoList.each(img => { // 通过位置判断图片滑出来了就加载 img.src = $(img).attr('data-src'); }); } } // 点击分页的时候就初始化一个图片懒惰加载的 $('.page').on('click', function () { new ImageLazyLoader($('img.photo')); });
这是一个图片懒惰加载的模型，每次点分页的时候就会清掉上一页的数据更新为当前页的DOM，并重新初始化一个懒惰加载的引擎。它里面监听了scroll事件，对传进来的图片列表的DOM进行处理。每点一次分页就会重新new一个，这里就发生了内存泄露，主要是以下3行代码导致的：
$(window).on('scroll', () => { this.showImage($photoList); });
因为这里的事件绑定形成了一个闭包，this/$photoList这两个变量一直没有被释放，this是指向ImageLazyLoader的实例，而$photoList是指向DOM结点，当清除掉上一页的数据的时候，相关DOM结点已经从DOM树分离出来了，但是仍然还有一个$photoList指向它们，导致这些DOM结点无法被垃圾回收一直在内存里面，就发生了内存泄露。由于this变量也被闭包困住了没有被释放，所以还有一个ImageLazyLoader的实例发生内存泄露。
这个的解决方法比较简单，就是销毁实例的时候把绑定的事件off掉，如下代码所示：
class ImageLazyLoader { constructor ($photoList) { this.scrollShow = () => { this.showImage($photoList); }; $(window).on('scroll', this.scrollShow); } // 新增一个事件解绑 clear () { $(window).off('scroll', this.scrollShow); } showImage ($photoList) { $photoList.each(img => { // 通过位置判断图片滑出来了就加载 img.src = $(img).attr('data-src'); }); // 判断如果图片已全部显示，就把事件解绑了 if (this.allShown) { this.clear(); } } } // 点击分页的时候就初始化一个图片懒惰加载的 let lazyLoader = null; $('.page').on('click', function () { lazyLoader && (lazyLoader.clear()); lazyLoader = new ImageLazyLoader($('img.photo')); });
在每次实例化一个ImageLazyLoader之前把先把上一个实例clear掉，clear里面进行解绑，由于JS有构造函数但是没有解构函数，所以需要自己写一个clear，在外面手动调一下clear。同时在事件的执行过程的合适时机自动把事件给解绑了，上面是判断如果所有的图片都展示出来了那么就没必要监听scroll事件了直接解绑了。这样就能解决内存泄露的问题了，能够触发自动垃圾回收。
为什么把事件解绑了，就不会有闭包引用了呢？因为JS引擎检测到那个闭包没用了，就把那个闭包销毁了，那么闭包引用的外部变量也自然会被置空。
好了，基础知识就讲解到这里，现在用Chrome devtools的内存检测工具来实际操作一遍，方便发现页面的一些内存泄露行为。为了避免装给浏览器装的一些插件造成影响，使用Chome的隐身模式页面，它会把所有的插件都给禁掉。
然后打开devtools，切到Memory的tab，选中Heap snapshot，如下所示：
