深入淺出JavaScript記憶體流失(1)

在過去一些的時候，Web開發人員並沒有太多的去關注記憶體泄露問題。那時的頁面間聯絡大都比較簡單，並主要使用不同的串連地址在同一個網站中導航，這樣的設計方式是非常有利於瀏覽器釋放資源的。即使Web頁面運行中真的出現了資源泄漏，那它的影響也是非常有限而且常常是不會被人在意的。

BKJIA推薦閱讀：早該知道的7個JavaScript技巧

今天人們對Web應用有了高更的要求。一個頁面很可能數小時不會發生URL跳轉，並同時通過Web服務動態更新頁面內容。複雜的事件關聯設計、基於對象的JavaScript和DHTML技術的廣泛採用，使得代碼的能力達到了其承受的極限。在這樣的情況和改變下，弄清楚記憶體泄露方式變得非常的急迫，特別是過去這些問題都被傳統的頁面導航方法給屏蔽了。

還算好的事情是，當你明確了希望尋找什麼時，記憶體泄露方式是比較容易被確定的。大多數你能遇到的泄露問題我們都已經知道，你只需要少量額外的工作就會給你 帶來好處。雖然在一些頁面中少量的小泄漏問題仍會發生，但是主要的問題還是很容易解決的。

泄露方式

在接下來的內容中，我們會討論記憶體泄露方式，並為每種方式給出樣本。其中一個重要的樣本是JavaScript中的Closure技術，另一個樣本是在事件執行 中使用Closures。當你熟悉本樣本後，你就能找出並修改你已有的大多數記憶體流失問題，但是其它Closure相關的問題可能又會被忽視。

現在讓我們來看看這些個方式都有什麼：

1、循環參考(Circular References) — IE瀏覽器的COM組件產生的對象執行個體和網頁指令碼引擎產生的對象執行個體相互引用，就會造成記憶體流失。這也是Web頁面中我們遇到的最常見和主要的泄漏方式；

2、內建函式引用(Closures) — Closures可以看成是目前引起大量問題的迴圈應用的一種特殊形式。由於依賴指定的關鍵字和文法結構，Closures調用是比較容易被我們發現的；

3、頁面交叉泄漏(Cross-Page Leaks) — 頁面交叉泄漏其實是一種較小的泄漏，它通常在你瀏覽過程中，由於內部對象薄計引起。下面我們會討論DOM插入順序的問題，在那個樣本中你會發現只需要改動 少量的代碼，我們就可以避免對象薄計對對象構建帶來的影響；

4、貌似泄漏(Pseudo-Leaks) — 這個不是真正的意義上的泄漏，不過如果你不瞭解它，你可能會在你的可用記憶體資源變得越來越少的時候極度鬱悶。為了示範這個問題，我們將通過重寫 Script元素中的內容來引發大量記憶體的"泄漏"。

循環參考

循環參考基本上是所有泄漏的始作俑者。通常情況下，指令碼引擎通過垃圾收集器(GC)來處理循環參考，但是某些未知因數可能會妨礙從其環境中釋放資源。對於 IE來說，某些DOM對象執行個體的狀態是指令碼無法得知的。下面是它們的基本原則：