【正文】 60。(parentDiv)。(parentDiv)。(childDiv)。parentDiv = null 。childDiv = null 。}hostElement = null 。} function CleanMemory() // 而這個函數(shù)不會引發(fā)CrossPageLeaks { var hostElement = ( hostElement )。 // Doitalot,lookatTaskManagerformemoryresponse for (i = 0 。i 5000 。i ++ ){ var parentDiv = ( divonClick=39。foo()39。 )。 var childDiv = ( divonClick=39。foo()39。 )。 // Changingtheorderisimportant,thiswon39。tleak (parentDiv)。(childDiv)。(parentDiv)。(childDiv)。parentDiv = null 。childDiv = null 。}hostElement = null 。} / script / head body buttononclick = LeakMemory() MemoryLeakingInsert / button buttononclick = CleanMemory() CleanInsert / button divid = hostElement / div / body / html LeakMemory和CleanMemory這兩段函數(shù)的唯一區(qū)別就在于他們的代碼的循序，從代碼上看，兩段代碼的邏輯都沒有錯。但LeakMemory卻會造成泄露。原因是LeakMemory()會先建立起parentDiv和childDiv之間的連接，這時候，為了讓 childDiv能夠獲知parentDiv的信息，因此IE需要先建立一個臨時的scope對象。而后parentDiv建立了和 hostElement對象的聯(lián)系，parentDiv和childDiv直接使用頁面document的scope?？上У氖牵琁E不會釋放剛才那個臨 時的scope對象的內(nèi)存空間，直到我們跳轉(zhuǎn)頁面，這塊空間才能被釋放。而CleanMemory函數(shù)不同，他先把parentDiv和 hostElement建立聯(lián)系，而后再把childDiv和parentDiv建立聯(lián)系，這個過程不需要單獨建立臨時的scope，只要直接使用頁面 document的scope就可以了， 所以也就不會造成內(nèi)存泄露了詳細原因，大家可以看看。btw:IE 6中垃圾回收算法，就是從那些直接in scope的對象開始進行mark清除的：Every variable which is in scope is called a scavenger. A scavenger may refer to a number, an object, a string, whatever. We maintain a list of scavengers – variables are moved on to the scav list when they e into scope and off the scav list when they go out of scope.PseudoLeaks 這個被稱為“秀逗泄露”真是恰當(dāng)啊：）看看這個例子: html head scriptlanguage = JScript function LeakMemory(){ // Doitalot,lookatTaskManagerformemoryresponse for (i = 0 。i 5000 。i ++ ){ = functionfoo(){} 。／／看內(nèi)存會不斷增加}} / script / head body buttononclick = LeakMemory() MemoryLeakingInsert / button scriptid = hostElement function foo(){} / script / body / html MS是這么解釋的，這不是內(nèi)存泄漏。如果您創(chuàng)建了許多無法獲得也無法釋放的對象，那才是內(nèi)存泄漏。在這里，您將創(chuàng)建許多元素，Internet Explorer 需要保存它們以正確呈現(xiàn)頁面。Internet Explorer 并不知道您以后不會運行操縱您剛剛創(chuàng)建的所有這些對象的腳本。當(dāng)頁面消失時（當(dāng)您瀏覽完，離開瀏覽器時）會釋放內(nèi)存。它不會泄漏。當(dāng)銷毀頁面時，會中斷循 環(huán)引用。 @THEMAX SetupLeak() 函數(shù)中 myGlobalObject = ( LeakedDiv )。 則 myGlobalObject有了一個指向DOM對象 LeakedDiv 的引用， 而后 ( LeakedDiv ).expandoProperty = myGlobalObject。 使得DOM對象 LeakedDiv 有一個屬性expandoProperty引用指向myGlobalObject。 這樣myGlobalObject和DOM對象 LeakedDiv 分別有引用指向?qū)Ψ剑跃脱h(huán)引用了。 函數(shù)BreakLeak() 則清除了DOM對象 LeakedDiv 向myGlobalObject的引用， 解決循環(huán)引用問題。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 如果你問的是第二段代碼，那么就比較復(fù)雜了。 這涉及到Closure的問題，你可以看看文章中給出的其他鏈接文章，例如zkjbeyond對Closure一文的翻譯。 大致的原因是因為ClickEventHandler()是AttachEvents()的一個內(nèi)嵌函數(shù)， AttachEvents()函數(shù)執(zhí)行后，把ClickEventHandler()函數(shù)綁定在element對象的onclick事件上。 這樣，element對象就有個間接引用指向ClickEventHandler()函數(shù)的一個實例。 又正是因為ClickEventHandler()是一個內(nèi)嵌函數(shù)，因此會為這個實例構(gòu)造一個scope，這個scope中包括了父函數(shù)，也就是 AttachEvents()函數(shù)中的局部變量和參數(shù)，而這兒的參數(shù)剛好就是element，所以ClickEventHandler()函數(shù)的實例同時 又間接引用了element。想了想,還是覺得第一段應(yīng)該沒有內(nèi)存泄漏. 如果改成 var myGlobalObject = {}。 function SetupLeak() // 產(chǎn)生循環(huán)引用，因此會造成內(nèi)存泄露 { // First set up the script scope to element reference = (LeakedDiv)。 // Next set up the element to script scope reference ( LeakedDiv ).expandoProperty = myGlobalObject。 } 那就產(chǎn)生內(nèi)存泄漏了. 因為在原來的那個代碼中,myGlobalObject只是一個變量,指向domobj,而自身并不是一個jsobject. 這段代碼應(yīng)該是在微軟官方的文章上改的,不過好像改失敗了,囧... 原文這樣的: html head script language=JScript function Encapsulator(element) { // Set up our element = element。 // Make our circular reference = this。 } function SetupLeak() { // The leak happens all at once new Encapsulator((LeakedDiv))。 } function BreakLeak() { (LeakedDiv).expandoProperty = null。 } /script /head body onload=SetupLeak() onunload=BreakLeak() div id=LeakedDiv/div /body /html 個人看法,大家繼續(xù)討論...被內(nèi)存泄漏折騰壞了,好像firefox也有.18