在上次遇到DWR内存泄漏问题后根据网上的内容对JS文件进行修改，修改后发现还有一些兼容的问题，同时还出现不能调用的一些情况。

而且根据统计DWR就算内存泄漏，也不是特别严重，除非你一个浏览器跑几天不关闭，而且实时刷新！

经过再次查询，得知IE浏览器有自己的一个垃圾回收的函数：CollectGarbage();

CollectGarbage,是IE的一个特有属性,用于释放内存的使用方法嘛应该是,将该变量或引用对象,设置为null或delete

然后在进行释放动作在做CollectGarbage前,要必需清楚的两个必备条件:

引用

- 一个对象在其生存的上下文环境之外，即会失效。

- 一个全局的对象在没有被执用(引用)的情况下，即会失效。

对于对象何时失效，有这样的一些解释：

function testObject() {
var _obj1 = new Object();
}

function testObject2() {
var _obj2 = new Object();
return _obj2;
}

// 示例1
testObject();

// 示例2
testObject2()

// 示例3
var obj3 = testObject2();
obj3 = null;

// 示例4
var obj4 = testObject2();
var arr = [obj4];
obj3 = null;
arr = [];

在这四个示例中：

- “示例1”在函数testObject()中构造了_obj1，但是在函数退出时，它就已经离开了函数的上下文环境，因此_obj1失效了；

- “示例2”中，testObject2()中也构造了一个对象_obj2并传出，因此对象有了“函数外”的上下文环境(和生存周期)，然而由于函数
的返回值没有被其它变量“持有”，因此_obj2也立即失效了；

- “示例3”中，testObject2()构造的_obj2被外部的变量obj3持用了，这时，直到“obj3=null”这行代码生效时，_obj2才会因为引用关系消失而失效。

- 与示例3相同的原因，“示例4”中的_obj2会在“arr=[]”这行代码之后才会失效。

另外我发现许多人都说了这样一句话：

最后之最后，关于GC的一个补充说明：在IE窗体被最小化时，IE将会主动调用一次CollectGarbage()函数。这使得IE窗口在最小化之后，内存占用会有明显改善。

我只能说，调用CollectGarbage()函数会有意外的收获，但是他不是万能的，也不是调用就能释放内存更不是说调用后和将浏览器最小化一次的效果一样。

我们是每秒五次刷新，每次刷新点有一百多处，这样浏览器的DOM始终是在增加和更新东西。算下来，就是跑一个小时也是有很大消耗的。

更何况我们的软件要跑在一个定制的机器上，发现这个机器的硬件有兼容问题，我们将浏览器更新到IE7.0，进行数据实时刷新后发现，内存一直增长，直到浏览器崩溃。但是不同机器崩溃的时机不同。

我在每次更新后调用垃圾回收函数，发现浏览器的内存仍在增加，但是间隔的有增有加，虽然总体还是在增加。由此，我们在那个机器上跑了十几个小时，浏览器内存没有超过50M。

很少有那个页面会这样大量的刷新，并跑这么长时间吧，可是我们遇到了。

把问题归咎与DWR我发现不是很合理，至少现在我这么觉得，但是对于页面有大量刷新和需要长时间运行这个需求来说，我觉得还是需要深入研究一下的。