导致IE浏览器内存泄漏的研究

昨天打开一个门户网站的时候发现IE浏览器有点卡，这个时候打开了任务管理器查看了一下，发现IE浏览器进程的内存竟然达到了423，145K，记得平时浏览这个网站的时候还很正常，这个网站的JS广告代码很多，怀疑JS导致IE发生了内存泄漏，因此打算来检测一下，用的工具是IE的插件js memory leaks dector，但是从新进行了一些可能引起内存泄漏的操作后，发现测试的结果好像并没有问题，没有发现关于内存泄漏的地方。这个时候想到会不会是IFRAM没有被销毁，加重了ie浏览器的负担，损耗了大量的内存使用。

怀着一探到底去决心，去网上查找了一些技术文档，发现用SIEVE来测试此类系统的IE内存泄漏时，通常在报表刷新的过程中，通常是会发生IE的内存泄漏的，因此，用SIEVE从新测试了一下，果然跟网上说的一样，登录后，内存泄漏显示位58，在报表每次刷新的时候，内存泄漏显示+1，在切换报表的时候，内存泄漏在原基础上又增加了7，然后再退出的时候，内存泄漏由原来的77一下增加到了1200多。通过此工具记录下的发生内存泄漏的ID和TAG名称，可查找出发生内存泄漏的代码。

    关于内存泄漏这个词的理解，其实比较通俗简单的意思就是已经不再被使用的资源，哪些资源实际上是应该被释放的资源，而现在程序里面并没有被释放除去，所以导致程序占用的内存一直在增多的现象。针对IE浏览器发生的内存泄漏，引起IE内存泄漏的主要情况为js对象实例跟dom对象的相互引用、“内部函数引用(Closures)”以及DOM插入顺序泄漏，其中最常见的就是js对象实例跟dom对象的相互引用，对基于对象的JScript，一个通常用法是通过封装JScript对象来扩充DOM对象，在构建的过程中，通常在涉及DOM对象时，建立一个对DOM对象的引用，DOM对象也建立一个指向JS对象实例的引用，这就形成了一个循环，虽然不管js调用dom还是从dom反向找到实例都非常方便，但如果在对象销毁或document unload的时候不去解除他们之间的引用，就会引起内存泄漏。JS的GC可以识别循环，当对dom节点和事件处理函数的引用消失，会自动回收，但是IE自己的内存管理器并不识别循环，因此占用的内存没有被回收，就会发生内存泄漏。例如：我在用IE浏览器访问当前的页面进行刷新时，由于在之前还访问了别的页面占用的内存一直没有释放，导致程序占用的内存不断的升高。

Java leak memorys detector通过在访问每个URL结束时给出测试解果，如果IE在访问当前页面的过程中没有发生内存泄漏，那么URL显示为绿色，如果发生了内存泄漏，显示为红色，通过这个软件我们可以记录下发生内存泄漏的详细信息，左侧部分显示发生内存泄漏的代码位置为粗体字，在中间的两格中显示详细信息与CALL STACK，右侧显示发生内存泄漏的完整的代码。

SIEVE通过在地址栏输入要访问的系统地址来进行操作测试，中间直接显示要访问的系统界面，下栏显示COM和DOM的使用情况，右侧显示实时数据：内存使用情况，内存泄漏等，如果发生内存泄漏可以通过右侧数据看出，然后点击show leaks的按钮可以看到发生内存泄漏的详细信息如ID等，不过不是所有发生内存泄漏的都会被记录下所有的详细信息，只有很少一部分ID被记录下来，还可通过界面上的自动刷新按钮对系统进行刷新，代替了手工刷新。但是此工具使用起来占用内存很大，进行操作比较多后会无响应，有些操作还会引起工具自动关闭，在复制出内存泄漏信息时只能选择全部的详细信息，不能滤掉一些没有必要的信息和空信息，造成使用不是很方便。

    写在最后，关于IE浏览器内存泄漏的查找确实是一件比较麻烦的，首先要求工作人员本身需要拥有一定的内存泄漏的查找经验，更重要的是需要有一定的耐心，当然，如果你有一个好用的工具查找起来会更加的方便有效，其实我个人对于IE浏览器的内存泄漏测试和查找我也是处于刚刚学习起步的状态，此次整个研究的过程希望与大家一起来分享经验，大家共同的学习进步。