摘要:局部變量只在函數(shù)執(zhí)行過程中存在。此時,局部變量就沒有存在的必要了,因此可以釋放它們的內(nèi)存以供將來使用。總結(jié)一般情況下,局部變量的生命周期為函數(shù)對象執(zhí)行到執(zhí)行結(jié)束,全局變量的生命周期為瀏覽器打開和關(guān)閉。
垃圾收集
JavaScript具有自動垃圾收集機制,也就是說,執(zhí)行環(huán)境會負責管理代碼執(zhí)行中使用的內(nèi)存。在C和C++語言中,開發(fā)人員一項基本任務(wù)就是手工跟蹤內(nèi)存的使用情況,這是造成許多問題的一個根源。在編寫JavaScript程序時,開發(fā)人員不用在關(guān)心內(nèi)存使用問題,所需內(nèi)存的分配以及無用內(nèi)存的回收完全實現(xiàn)了自動管理。這種垃圾收集機制的原理其實很簡單:找出那些不在繼續(xù)使用的變量,然后釋放其占用的內(nèi)存。為此垃圾收集器會按照固定的事件間隔(或代碼執(zhí)行中預定的收集時間),周期性的執(zhí)行這一操作。
記:既然有垃圾收集器,那么本身垃圾收集也是耗用內(nèi)存的,且宿主環(huán)境是瀏覽器時,本身獲得的內(nèi)存不會是全部內(nèi)存,為防止瀏覽器耗盡內(nèi)存而系統(tǒng)崩潰。
下面來分析一下函數(shù)中局部變量的正常生命周期。局部變量只在函數(shù)執(zhí)行過程中存在。而在這個過程中,會為局部變量在棧(或堆)內(nèi)存上分配相應(yīng)的空間,以便存儲它們的值。然后在函數(shù)中使用這些變量,直至函數(shù)執(zhí)行結(jié)束。此時,局部變量就沒有存在的必要了,因此可以釋放它們的內(nèi)存以供將來使用。在這種情況下,很容易判斷變量是否還有存在的必要;但并非所以情況下都這么容易得出結(jié)論。
垃圾收集器必須跟蹤哪個變量有用哪個變量沒用,對于不再有用的變量打上標記,已備將來收回所占用的內(nèi)存。用于標識無用變量的策略可能會因?qū)崿F(xiàn)而異。
總結(jié):
一般情況下,局部變量的生命周期為函數(shù)(對象)執(zhí)行到執(zhí)行結(jié)束,全局變量的生命周期為瀏覽器打開和關(guān)閉。
根據(jù)數(shù)據(jù)類型(值、引用)分配棧、堆內(nèi)存。(這里有一些爭議,認為JavaScript這類高級語言用stack和heap解釋不是很準確。并且JS中的值類型實際上也是一種"對象")
前端基礎(chǔ)進階(一):內(nèi)存空間詳細圖解
對于無用變量的回收采取先標記,后回收策略,具體執(zhí)行垃圾收集器。
回收策略:標記清除JavaScript中最常用的垃圾收集方式是標記清除(mark-and-sweep)。當變量進入環(huán)境(例如,在函數(shù)中聲明一個變量)時,將這個變量標記為"進入環(huán)境"(進入執(zhí)行棧?)。從邏輯上講,永遠不能釋放進入環(huán)境的變量所占用的內(nèi)存,因為只要執(zhí)行流進入相應(yīng)的環(huán)境,就可能用到它們。而當變量離開環(huán)境時,則將其標記為"離開環(huán)境"。
可以使用任何方式標記變量,如翻轉(zhuǎn)某個特殊的位來紀錄一個變量何時進入環(huán)境,或者使用一個“進入環(huán)境的”變量列表及一個"離開環(huán)境的"變量列表來跟蹤哪個變量發(fā)生變化。
垃圾收集器在運行時時候會給存儲在內(nèi)存中所有變量都加上標記(問題:加標記這個動作是否也會占用內(nèi)存?)。然后,它會去掉環(huán)境中的變量以及被環(huán)境中的變量引用的變量的標記。而在此之后再被加上標記的變量將被視為準備刪除的變量,原因是環(huán)境中的變量已經(jīng)無法訪問到這些變量了。最后,垃圾收集器完成內(nèi)存清除工作,銷毀那些帶標記的值并回收它們所占用的內(nèi)存空間。
完全抽象不起來:)
回收策略:引用計數(shù)另一種不太常見的垃圾收集策略叫做引用計數(shù)(reference counting)。引用技術(shù)的含義是跟蹤紀錄每個值被引用的次數(shù)。當聲明了一個變量并將一個引用類型值賦給該變量時,則這個值的引用次數(shù)就是1。如果同一個值又被賦給另一個變量,則該值的引用次數(shù)加1。相反,如果包含對這個值引用的變量又取得了另外一個值。,則這個值的引用次數(shù)減1。
自己抽象的圖:)
當這個值的引用次數(shù)變成0時,則說明沒有辦法在訪問這個值了,因而就可以將其占用的內(nèi)存空間回收起來。這樣,當垃圾收集器下次運行時,它就會釋放那些引用次數(shù)為0的值所占用的內(nèi)存。
《JS高程3》曾說JavaScript不允許直接訪問內(nèi)存地址,而是通過對外引用內(nèi)存地址(哈希表)來實現(xiàn)訪問,這個回收方式是否可以看成是內(nèi)存地址對外顯現(xiàn)的次數(shù)?
Netscpae Navigatior3.0是最早使用引用技術(shù)策略的瀏覽器,但很快它就遇到了一個嚴重的問題:循環(huán)引用。循環(huán)引用指的是對象A中一個指向?qū)ο驜的指針,而對象B也包含一個指向?qū)ο驛的引用。如下:
function problem() { var objA = new Object(); var objB = new Object(); objA.someOtherObject = objB; objB.anotherObject = objA; }
objA和objB通過各自的屬性相互引用;也就是說,這兩個對象的引用次數(shù)都是2。在采用標記清除策略的實現(xiàn)中,由于函數(shù)執(zhí)行之后,這兩個對象都離開了作用域,因此這種相互引用不是問題。
但在采用引用計數(shù)策略的實現(xiàn)中,當函數(shù)執(zhí)行完畢后,因為它們的引用次數(shù)永遠不會是0,假如這個函數(shù)被重復多次調(diào)用,就會導致大量內(nèi)存得不到回收。為此,Netscape在Navigation4.0中放棄了引用計數(shù)方式,轉(zhuǎn)而采用標記清除來實現(xiàn)其垃圾收集機制。可是,引用計數(shù)導致的麻煩并未就此終結(jié)。
我們知道,IE中有一部分對象并不是原生JavaScript對象。例如,其BOM和DOM中的對象就是使用C++以COM(Component Object Model,組件對象模型)對象的形式實現(xiàn)的,而COM對象的垃圾收集機制采用的就是引用計數(shù)策略。因此,即使IE的JavaScript引擎是使用標記清除策略實現(xiàn)的,但JavaScript訪問的COM對象依然是基于引用計數(shù)策略的。換句話說,只要在IE中涉及COM對象,就會存在循環(huán)引用的問題。
下面這個簡單的例子,展示了COM對象導致的循環(huán)引用問題:
var e = document.getElementById("some_element"); var myObject = new Object(); myObject.element = e; e.someObject = myObject;
一個DOM元素(element,也是對象)與一個原生JavaScript對象(myObject)之間創(chuàng)建了循環(huán)引用。
其中,變量myObject有一個名為e的屬性指向element對象;而變量e也有一個屬性名叫someObject回指myObject。由于存在這個循環(huán)引用,即使將例子中的DOM從頁面中移除,它也永遠不會被回收。
為了避免類似這樣的循環(huán)引用問題,最好是在不使用它們的時候手工斷開原生JavaScript對象與DOM元素之間的鏈接。例如,可以使用下面的代碼消除前面例子創(chuàng)建的循環(huán)引用:
myObject.element = null; element.someObject = null;
將變量設(shè)置為null意味著切斷變量與它此前引用的值之間的鏈接。當垃圾收集器下次運行時,就會刪除這些值并回收它們占用的內(nèi)存。
性能問題垃圾收集器周期性運行的,而且如果為變量分配的內(nèi)存數(shù)量可觀,那么回收工作量也是相當大的。在這種情況下,確定垃圾收集器的時間間隔是一個非常重要的問題。
說道垃圾收集器多久時間運行一次,不禁讓人聯(lián)想起IE因此而聲名狼藉的性能問題。IE的垃圾收集器是根據(jù)內(nèi)存分配量運行的,具體一點說就是256個變量、4096個對象(或數(shù)組)字面量和數(shù)組元素或者64KB的字符串。達到上述任何一個臨界值,垃圾收集器都會運行。這種實現(xiàn)方式問題在于,如果一個腳本包含那么多變量,那么該腳本可能會在其生命周期中一直保持那么多變量。而這樣一來,垃圾收集器不得不頻繁的運行。結(jié)果,由此引發(fā)的嚴重性能問題促使IE7重寫了其垃圾收集例程。
事實上,有點瀏覽器可以觸發(fā)垃圾收集過程,但我們不建議讀者這樣做。在IE中,調(diào)用window.CollectGarbage()方法會立即執(zhí)行垃圾收集。
管理內(nèi)存JavaScript在進行內(nèi)存管理及垃圾收集時面臨問題最主要的是,分配給web瀏覽器的可用內(nèi)存數(shù)量比桌面應(yīng)用程序的少,防止運行JavaScript網(wǎng)頁耗盡系統(tǒng)內(nèi)存而導致系統(tǒng)崩潰。內(nèi)存限制問題不僅會影響給變量分配內(nèi)存,同時還會影響調(diào)用棧以及一個線程中能夠同時執(zhí)行的語句數(shù)量。
確保占用最少的內(nèi)存可以讓頁面獲得更好的性能。而優(yōu)化內(nèi)存占用的最佳方式,就是為執(zhí)行中的代碼只保存必要的數(shù)據(jù)。一旦數(shù)據(jù)不再有用,最好通過將其值設(shè)置為null來釋放其引用——這個做法叫做解除引用(dereferencing)。這一做法用于大多數(shù)全局變量和全局對象的屬性。局部變量會在它們離開執(zhí)行環(huán)境時自動解除引用:
function createPerson(name) { var localPerson = new Object(); localPerson.name = name; return localPerson; } var globalPerson = createPerson("Nicholas"); // 手工解除globalPerson的引用 globalPerson = null;
localPerson在函數(shù)執(zhí)行完畢就離開執(zhí)行環(huán)境,因此無需我們顯式地去為它解除引用。但是對于全局變量globalPerson而言,則需要我們在不使用它的時候手工為它解除引用,設(shè)置為null。
解除一個值的引用并不意味著自動回收該值所占用的內(nèi)存。解除引用的真正作用是讓值脫離執(zhí)行環(huán)境,以便垃圾收集器下次運行時將其回收。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/83447.html
摘要:解決方式是,當我們不使用它們的時候,手動切斷鏈接淘汰把和對象轉(zhuǎn)為了真正的對象,避免了使用這種垃圾收集策略,消除了以下常見的內(nèi)存泄漏的主要原因。以上參考資料高程垃圾收集類內(nèi)存泄漏及如何避免內(nèi)存泄露及解決方案詳解類內(nèi)存泄漏及如何避免 showImg(http://ww1.sinaimg.cn/large/005Y4rCogy1ft1ikzcqzqj30ka0et77a.jpg); 前言 起...
摘要:但是如果一個值不再用到了,引用次數(shù)卻不為,垃圾回收機制卻無法釋放這塊內(nèi)存,從而導致內(nèi)存泄漏。內(nèi)存泄漏垃圾回收語言的內(nèi)存泄漏主因是不需要的引用。常見內(nèi)存泄漏意外的全局變量處理未定義變量的方式比較寬松未定義的變量會在全局對象創(chuàng)建一個新變量。 簡答題: settimeout 與 setInterval的區(qū)別, 及對他們的內(nèi)存的分析 區(qū)別 setTimeout是在一段時間后調(diào)用指定函數(shù)(僅一...
摘要:但是如果一個值不再用到了,引用次數(shù)卻不為,垃圾回收機制卻無法釋放這塊內(nèi)存,從而導致內(nèi)存泄漏。內(nèi)存泄漏垃圾回收語言的內(nèi)存泄漏主因是不需要的引用。常見內(nèi)存泄漏意外的全局變量處理未定義變量的方式比較寬松未定義的變量會在全局對象創(chuàng)建一個新變量。 簡答題: settimeout 與 setInterval的區(qū)別, 及對他們的內(nèi)存的分析 區(qū)別 setTimeout是在一段時間后調(diào)用指定函數(shù)(僅一...
摘要:但是如果一個值不再用到了,引用次數(shù)卻不為,垃圾回收機制卻無法釋放這塊內(nèi)存,從而導致內(nèi)存泄漏。內(nèi)存泄漏垃圾回收語言的內(nèi)存泄漏主因是不需要的引用。常見內(nèi)存泄漏意外的全局變量處理未定義變量的方式比較寬松未定義的變量會在全局對象創(chuàng)建一個新變量。 簡答題: settimeout 與 setInterval的區(qū)別, 及對他們的內(nèi)存的分析 區(qū)別 setTimeout是在一段時間后調(diào)用指定函數(shù)(僅一...
閱讀 2323·2023-04-26 00:28
閱讀 3067·2019-08-30 15:55
閱讀 2742·2019-08-30 12:47
閱讀 1550·2019-08-29 11:04
閱讀 3150·2019-08-28 18:14
閱讀 945·2019-08-28 18:11
閱讀 1671·2019-08-26 18:36
閱讀 3383·2019-08-23 18:21