這段時間挺忙，不過還好終於圓滿提交了產品 的一個重要feature，Enterprise Overall Dashboard ，有空再介紹一下。關於這個IE內存泄漏雖然是越來越鬱悶，不過鬱悶歸鬱悶，還是因該要有個善始善終，於是把最後一節翻完了放上來，這也好是個完整的系列。
貌似泄漏(Pseudo-Leaks)
在大多數時候，一些APIs的實際的行爲和它們預期的行爲可能會導致你錯誤的判斷內存泄漏。貌似泄漏大多數時候總是出現在同一個頁面的動態腳本操作中，而在從一個頁面跳轉到空白頁面的時候發生是非常少見的。那你怎麼能象排除頁面間泄漏 那樣來排除這個問題，並且在新任務運行中的內存使用量是否是你所期望的。我們將使用腳本文本的重寫來作爲一個貌似泄漏的示例。
象DOM插入順序問題那樣，這個問題也需要依賴創建臨時對象來產生"泄漏"。對一個腳本元素對象內部的腳本文本一而再再而三的反覆重寫，慢 慢地你將開始泄漏各種已關聯到被覆蓋內容中的腳本引擎對象。特別地，和腳本調試有關的對象被作爲完全的代碼對象形式保留了下來。
<
html
>
<
head
>
<
script
language
="JScript"
>
function
LeakMemory()
{
//
Do it a lot, look at Task Manager for memory response
for
(i
=
0
; i
<
5000
; i
++
)
{
hostElement.text
=
"
function foo() { }
"
;
}
}
</
script
>
</
head
>
<
body
>
<
button
onclick
="LeakMemory()"
>
Memory Leaking Insert
</
button
>
<
script
id
="hostElement"
>
function
foo()
{ }
</
script
>
</
body
>
</
html
>
如果你運行上面的示例代碼並使用任務管理器查看，當從"泄漏"頁面跳轉到空白頁面時，你並不會注意到任何腳本泄漏。因爲這種腳本泄
漏完全發生在頁面內部，而且當你離開該頁面時被使用的內存就會回收。對於我們原本所期望的行爲來說這樣的情況是糟糕的。你希望當重寫了腳本內容後，原來的
腳本對象就應該徹底的從頁面中消失。但事實上，由於被覆蓋的腳本對象可能已用作事件處理函數，並且還可能有一些未被清除的引用計數。正如你所看到的，這就
是貌似泄漏。在表面上內存消耗量可能看起來非常的糟糕，但是這個原因是完全可以接受的。
總結
每一位Web開發員可能都整理有一份自己的代碼示例列表，當他們在代碼中看到如列表中的代碼時，他們會意識到泄漏的存在並會使用一些開發技 巧來避免這些問題。這樣的方法雖然簡單便捷，但這也是今天Web頁面內存泄漏普遍存在的原因。考慮我們所討論的泄漏情景而不是關注獨立的代碼示例，你將會 使用更加有效的策略來解決泄漏問題。這樣的觀念將使你在設計階段就把問題估計到，並且確保你有計劃來處理潛在的泄漏問題。使用編寫加固代碼（譯者注：就是 異常處理或清理對象等的代碼）的習慣並且採取清理所有自己佔用內存的方法。雖然對這個問題來說可能太誇張了，你也可能幾乎從沒有見到編寫腳本卻需要自己清 理自己佔用的內存的情況；使這個問題變得越來越顯著的是，腳本變量和expando屬性間存在的潛在泄漏可能。
如果對模式和設計感興趣，我強烈推薦Scott的這篇blog
，
因爲其中演示了一個通用的移除基於閉包泄漏的示例代碼。當然這需要我們使用更多的代碼，但是這個實踐是有效的，並且改進的場景非常容易在代碼中定位並進行
調試。類似的注入設計也可以用在基於expando屬性引起的循環引用中，不過需要注意所註冊的方法自身不要讓泄漏(特別使用閉包的地方)跑掉。
About the author
Justin Rogers recently joined the Internet Explorer team as an Object
Model developer working on extensibility and previously worked on such
notable projects as the .NET QuickStart Tutorials, .NET Terrarium, and
SQL Reporting Services Management Studio in SQL Server 2005.
[全文完] 注意: 本翻譯未經作者授權，任何轉載責任自負。