簡單三步，搞掂記憶體流失

原文地址：http://www.jackslocum.com/blog/2006/10/02/3-easy-steps-to-avoid-javascript-memory-leaks/你可能還未知道，你瀏覽的大多數的js網站，會引起 記憶體流失。聽起來有點誇張，但這是事實，難道我會騙你嗎?
泄漏監視器Leak Monitor 這是個方便的FireFox擴充，當你離開那頁的時候它便會指向JavsScript對象，如果出現泄漏的話會彈出一個視窗顯示細節內容，而且能夠告訴你是那個對象或函數引起的泄漏。
離開http://script.aculo.us/的時候
這應該我是最常見的泄漏 prototype.js, line 74:3 The Dojo Mail 例子頁面
嚴重的泄漏,一下子彈出兩個視窗 (注意捲軸!)。 Word Press
這個更離譜。我每次寫完Word press,就會出現！

訪問一般的網站，你會發現大多數網站都會出現這類問題。的確，如果一些網站沒有經過這樣的測試，多少會讓人感到震驚，--本來適當一下的修改就可以確保這種問題不會發生。
雖然這網站（Jack'sBlog、範例）統統都是JavaScript的，但你不必擔心任何泄漏的危險。

如下簡單的三步：
1. 當你完成後，設定你的 XMLHttpRequest onreadystatechange handlers 為null,
我使用 YAHOO.util.Connect 來進行XHR連結 ，因為它使用了 polling mechanism來代替readstate, 這樣我不用手工set null了。我推薦你，在允許的情況下，使用YAHOO.util.Connect (或建於其之上的 YAHOO.ext.UpdateManager)。
2. 在unload事件中清除所有 DOM event handlers object ，如果它們有引用 (Refence)的機會的話。
能夠讓Library做的，就不要用自己的方法做！ 對於事件event的機制，我均使用了YAHOO.util.Event來處理. 其它的library (prototype, dojo, etc) 亦有自己的相應的機制來處理。 --儘管我不清楚它們的執行效率去到那裡。 如果你再仔細看看上面的，你會發現上面的泄漏代碼都會關聯到這些library裡面去（用事實證明事故的源頭，Frank注）
3.除了一些基本類型的資料primitive value （String 、Number），切勿放其它任何東西在 DOM expando 或 property 。當然，你能保證及時清除它的話，便是一個例外。
這就是最重要的金科玉律了。在DOM expando放東西，你會覺得很方便, 然後用 $()擷取它, 但千萬不要這樣做。 真的，我知道你在想什麼，現在的我已經有線想妄想症的認了.沒錯，很多場合都會把JS對象放到 DOM expando，也沒啥狀況發生，但也會有很多。。。。這種情況不容易檢查出來啊！(例如：閉包closures). 所以要避免任何可能的發生,我只會按照這樣的規律做.

摘要

解決這個問題並不是太難。它不需要任何技巧或經驗之談。只要注意好以上幾點，一個新手novice也知道如何避免泄漏。
請拜託一些大網站（包括新的 Yahoo Mail!?!?），花點時間，做足功夫，讓我（或其他人）瀏覽你的網頁而不遭受記憶體流失。