在上次遇到DWR內存泄漏問題后根據網上的內容對JS文件進行修改，修改后發(fā)現還有一些兼容的問題，同時還出現不能調用的一些情況。

而且根據統(tǒng)計DWR就算內存泄漏，也不是特別嚴重，除非你一個瀏覽器跑幾天不關閉，而且實時刷新！

經過再次查詢，得知IE瀏覽器有自己的一個垃圾回收的函數：CollectGarbage();

CollectGarbage,是IE的一個特有屬性,用于釋放內存的使用方法嘛應該是,將該變量或引用對象,設置為null或delete

然后在進行釋放動作在做CollectGarbage前,要必需清楚的兩個必備條件:

引用

- 一個對象在其生存的上下文環(huán)境之外，即會失效。

- 一個全局的對象在沒有被執(zhí)用(引用)的情況下，即會失效。

對于對象何時失效，有這樣的一些解釋：

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，但是在函數退出時，它就已經離開了函數的上下文環(huán)境，因此_obj1失效了；

- “示例2”中，testObject2()中也構造了一個對象_obj2并傳出，因此對象有了“函數外”的上下文環(huán)境(和生存周期)，然而由于函數
的返回值沒有被其它變量“持有”，因此_obj2也立即失效了；

- “示例3”中，testObject2()構造的_obj2被外部的變量obj3持用了，這時，直到“obj3=null”這行代碼生效時，_obj2才會因為引用關系消失而失效。

- 與示例3相同的原因，“示例4”中的_obj2會在“arr=[]”這行代碼之后才會失效。

另外我發(fā)現許多人都說了這樣一句話：

最后之最后，關于GC的一個補充說明：在IE窗體被最小化時，IE將會主動調用一次CollectGarbage()函數。這使得IE窗口在最小化之后，內存占用會有明顯改善。

我只能說，調用CollectGarbage()函數會有意外的收獲，但是他不是萬能的，也不是調用就能釋放內存更不是說調用后和將瀏覽器最小化一次的效果一樣。

我們是每秒五次刷新，每次刷新點有一百多處，這樣瀏覽器的DOM始終是在增加和更新東西。算下來，就是跑一個小時也是有很大消耗的。

更何況我們的軟件要跑在一個定制的機器上，發(fā)現這個機器的硬件有兼容問題，我們將瀏覽器更新到IE7.0，進行數據實時刷新后發(fā)現，內存一直增長，直到瀏覽器崩潰。但是不同機器崩潰的時機不同。

我在每次更新后調用垃圾回收函數，發(fā)現瀏覽器的內存仍在增加，但是間隔的有增有加，雖然總體還是在增加。由此，我們在那個機器上跑了十幾個小時，瀏覽器內存沒有超過50M。

很少有那個頁面會這樣大量的刷新，并跑這么長時間吧，可是我們遇到了。

把問題歸咎與DWR我發(fā)現不是很合理，至少現在我這么覺得，但是對于頁面有大量刷新和需要長時間運行這個需求來說，我覺得還是需要深入研究一下的。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論