heap與stack的研究
摘至 聰明豬的blog
Thinking in java第四章的內(nèi)容是關(guān)于內(nèi)存分配和初始化的,對(duì)這一章的學(xué)習(xí)帶出了我以往學(xué)習(xí)中的一個(gè)模糊點(diǎn):究竟什么是堆存儲(chǔ)(Heap)?什么是棧存儲(chǔ)(Stack)?有什么區(qū)別呢?翻了不少資料,補(bǔ)了這一課,覺得非常受用.
2.1 內(nèi)存分配策略
按照編譯原理的觀點(diǎn),程序運(yùn)行時(shí)的內(nèi)存分配有三種策略,分別是靜態(tài)的,棧式的,和堆式的.
靜態(tài)存儲(chǔ)分配是指在編譯時(shí)就能確定每個(gè)數(shù)據(jù)目標(biāo)在運(yùn)行時(shí)刻的存儲(chǔ)空間需求,因而在編譯時(shí)就可以給他們分配固定的內(nèi)存空間.這種分配策略要求程序代碼中不允許有可變數(shù)據(jù)結(jié)構(gòu)(比如可變數(shù)組)的存在,也不允許有嵌套或者遞歸的結(jié)構(gòu)出現(xiàn),因?yàn)樗鼈兌紩?huì)導(dǎo)致編譯程序無法計(jì)算準(zhǔn)確的存儲(chǔ)空間需求.
棧式存儲(chǔ)分配也可稱為動(dòng)態(tài)存儲(chǔ)分配,是由一個(gè)類似于堆棧的運(yùn)行棧來實(shí)現(xiàn)的.和靜態(tài)存儲(chǔ)分配相反,在棧式存儲(chǔ)方案中,程序?qū)?shù)據(jù)區(qū)的需求在編譯時(shí)是完全未知的,只有到運(yùn)行的時(shí)候才能夠知道,但是規(guī)定在運(yùn)行中進(jìn)入一個(gè)程序模塊時(shí),必須知道該程序模塊所需的數(shù)據(jù)區(qū)大小才能夠?yàn)槠浞峙鋬?nèi)存.和我們?cè)跀?shù)據(jù)結(jié)構(gòu)所熟知的棧一樣,棧式存儲(chǔ)分配按照先進(jìn)后出的原則進(jìn)行分配。
靜態(tài)存儲(chǔ)分配要求在編譯時(shí)能知道所有變量的存儲(chǔ)要求,棧式存儲(chǔ)分配要求在過程的入口處必須知道所有的存儲(chǔ)要求,而堆式存儲(chǔ)分配則專門負(fù)責(zé)在編譯時(shí)或運(yùn)行時(shí)模塊入口處都無法確定存儲(chǔ)要求的數(shù)據(jù)結(jié)構(gòu)的內(nèi)存分配,比如可變長(zhǎng)度串和對(duì)象實(shí)例.堆由大片的可利用塊或空閑塊組成,堆中的內(nèi)存可以按照任意順序分配和釋放.
2.2 堆和棧的比較
上面的定義從編譯原理的教材中總結(jié)而來,除靜態(tài)存儲(chǔ)分配之外,都顯得很呆板和難以理解,下面撇開靜態(tài)存儲(chǔ)分配,集中比較堆和棧:
從堆和棧的功能和作用來通俗的比較,堆主要用來存放對(duì)象的,棧主要是用來執(zhí)行程序的.而這種不同又主要是由于堆和棧的特點(diǎn)決定的:
在編程中,例如C/C++中,所有的方法調(diào)用都是通過棧來進(jìn)行的,所有的局部變量,形式參數(shù)都是從棧中分配內(nèi)存空間的。實(shí)際上也不是什么分配,只是從棧頂向上用就行,就好像工廠中的傳送帶(conveyor belt)一樣,Stack Pointer會(huì)自動(dòng)指引你到放東西的位置,你所要做的只是把東西放下來就行.退出函數(shù)的時(shí)候,修改棧指針就可以把棧中的內(nèi)容銷毀.這樣的模式速度最快,當(dāng)然要用來運(yùn)行程序了.需要注意的是,在分配的時(shí)候,比如為一個(gè)即將要調(diào)用的程序模塊分配數(shù)據(jù)區(qū)時(shí),應(yīng)事先知道這個(gè)數(shù)據(jù)區(qū)的大小,也就說是雖然分配是在程序運(yùn)行時(shí)進(jìn)行的,但是分配的大小多少是確定的,不變的,而這個(gè)"大小多少"是在編譯時(shí)確定的,不是在運(yùn)行時(shí).
堆是應(yīng)用程序在運(yùn)行的時(shí)候請(qǐng)求操作系統(tǒng)分配給自己內(nèi)存,由于從操作系統(tǒng)管理的內(nèi)存分配,所以在分配和銷毀時(shí)都要占用時(shí)間,因此用堆的效率非常低.但是堆的優(yōu)點(diǎn)在于,編譯器不必知道要從堆里分配多少存儲(chǔ)空間,也不必知道存儲(chǔ)的數(shù)據(jù)要在堆里停留多長(zhǎng)的時(shí)間,因此,用堆保存數(shù)據(jù)時(shí)會(huì)得到更大的靈活性。事實(shí)上,面向?qū)ο蟮亩鄳B(tài)性,堆內(nèi)存分配是必不可少的,因?yàn)槎鄳B(tài)變量所需的存儲(chǔ)空間只有在運(yùn)行時(shí)創(chuàng)建了對(duì)象之后才能確定.在C++中,要求創(chuàng)建一個(gè)對(duì)象時(shí),只需用new命令編制相關(guān)的代碼即可。執(zhí)行這些代碼時(shí),會(huì)在堆里自動(dòng)進(jìn)行數(shù)據(jù)的保存.當(dāng)然,為達(dá)到這種靈活性,必然會(huì)付出一定的代價(jià):在堆里分配存儲(chǔ)空間時(shí)會(huì)花掉更長(zhǎng)的時(shí)間!這也正是導(dǎo)致我們剛才所說的效率低的原因,看來列寧同志說的好,人的優(yōu)點(diǎn)往往也是人的缺點(diǎn),人的缺點(diǎn)往往也是人的優(yōu)點(diǎn)(暈~).
2.3 JVM中的堆和棧
JVM是基于堆棧的虛擬機(jī).JVM為每個(gè)新創(chuàng)建的線程都分配一個(gè)堆棧.也就是說,對(duì)于一個(gè)Java程序來說,它的運(yùn)行就是通過對(duì)堆棧的操作來完成的。堆棧以幀為單位保存線程的狀態(tài)。JVM對(duì)堆棧只進(jìn)行兩種操作:以幀為單位的壓棧和出棧操作。
我們知道,某個(gè)線程正在執(zhí)行的方法稱為此線程的當(dāng)前方法.我們可能不知道,當(dāng)前方法使用的幀稱為當(dāng)前幀。當(dāng)線程激活一個(gè)Java方法,JVM就會(huì)在線程的Java堆棧里新壓入一個(gè)幀。這個(gè)幀自然成為了當(dāng)前幀.在此方法執(zhí)行期間,這個(gè)幀將用來保存參數(shù),局部變量,中間計(jì)算過程和其他數(shù)據(jù).這個(gè)幀在這里和編譯原理中的活動(dòng)紀(jì)錄的概念是差不多的.
從Java的這種分配機(jī)制來看,堆棧又可以這樣理解:堆棧(Stack)是操作系統(tǒng)在建立某個(gè)進(jìn)程時(shí)或者線程(在支持多線程的操作系統(tǒng)中是線程)為這個(gè)線程建立的存儲(chǔ)區(qū)域,該區(qū)域具有先進(jìn)后出的特性。
每一個(gè)Java應(yīng)用都唯一對(duì)應(yīng)一個(gè)JVM實(shí)例,每一個(gè)實(shí)例唯一對(duì)應(yīng)一個(gè)堆。應(yīng)用程序在運(yùn)行中所創(chuàng)建的所有類實(shí)例或數(shù)組都放在這個(gè)堆中,并由應(yīng)用所有的線程共享.跟C/C++不同,Java中分配堆內(nèi)存是自動(dòng)初始化的。Java中所有對(duì)象的存儲(chǔ)空間都是在堆中分配的,但是這個(gè)對(duì)象的引用卻是在堆棧中分配,也就是說在建立一個(gè)對(duì)象時(shí)從兩個(gè)地方都分配內(nèi)存,在堆中分配的內(nèi)存實(shí)際建立這個(gè)對(duì)象,而在堆棧中分配的內(nèi)存只是一個(gè)指向這個(gè)堆對(duì)象的指針(引用)而已。
2.4 GC的思考
Java為什么慢?JVM的存在當(dāng)然是一個(gè)原因,但有人說,在Java中,除了簡(jiǎn)單類型(int,char等)的數(shù)據(jù)結(jié)構(gòu),其它都是在堆中分配內(nèi)存(所以說Java的一切都是對(duì)象),這也是程序慢的原因之一。
我的想法是(應(yīng)該說代表TIJ的觀點(diǎn)),如果沒有Garbage Collector(GC),上面的說法就是成立的.堆不象棧是連續(xù)的空間,沒有辦法指望堆本身的內(nèi)存分配能夠象堆棧一樣擁有傳送帶般的速度,因?yàn)?誰會(huì)為你整理龐大的堆空間,讓你幾乎沒有延遲的從堆中獲取新的空間呢?
這個(gè)時(shí)候,GC站出來解決問題.我們都知道GC用來清除內(nèi)存垃圾,為堆騰出空間供程序使用,但GC同時(shí)也擔(dān)負(fù)了另外一個(gè)重要的任務(wù),就是要讓Java中堆的內(nèi)存分配和其他語言中堆棧的內(nèi)存分配一樣快,因?yàn)樗俣鹊膯栴}幾乎是眾口一詞的對(duì)Java的詬病.要達(dá)到這樣的目的,就必須使堆的分配也能夠做到象傳送帶一樣,不用自己操心去找空閑空間.這樣,GC除了負(fù)責(zé)清除Garbage外,還要負(fù)責(zé)整理堆中的對(duì)象,把它們轉(zhuǎn)移到一個(gè)遠(yuǎn)離Garbage的純凈空間中無間隔的排列起來,就象堆棧中一樣緊湊,這樣Heap Pointer就可以方便的指向傳送帶的起始位置,或者說一個(gè)未使用的空間,為下一個(gè)需要分配內(nèi)存的對(duì)象"指引方向".因此可以這樣說,垃圾收集影響了對(duì)象的創(chuàng)建速度,聽起來很怪,對(duì)不對(duì)?
那GC怎樣在堆中找到所有存活的對(duì)象呢?前面說了,在建立一個(gè)對(duì)象時(shí),在堆中分配實(shí)際建立這個(gè)對(duì)象的內(nèi)存,而在堆棧中分配一個(gè)指向這個(gè)堆對(duì)象的指針(引用),那么只要在堆棧(也有可能在靜態(tài)存儲(chǔ)區(qū))找到這個(gè)引用,就可以跟蹤到所有存活的對(duì)象.找到之后,GC將它們從一個(gè)堆的塊中移到另外一個(gè)堆的塊中,并將它們一個(gè)挨一個(gè)的排列起來,就象我們上面說的那樣,模擬出了一個(gè)棧的結(jié)構(gòu),但又不是先進(jìn)后出的分配,而是可以任意分配的,在速度可以保證的情況下,Isn't it great?
但是,列寧同志說了,人的優(yōu)點(diǎn)往往也是人的缺點(diǎn),人的缺點(diǎn)往往也是人的優(yōu)點(diǎn)(再暈~~).GC()的運(yùn)行要占用一個(gè)線程,這本身就是一個(gè)降低程序運(yùn)行性能的缺陷,更何況這個(gè)線程還要在堆中把內(nèi)存翻來覆去的折騰.不僅如此,如上面所說,堆中存活的對(duì)象被搬移了位置,那么所有對(duì)這些對(duì)象的引用都要重新賦值.這些開銷都會(huì)導(dǎo)致性能的降低.
此消彼長(zhǎng),GC()的優(yōu)點(diǎn)帶來的效益是否蓋過了它的缺點(diǎn)導(dǎo)致的損失,我也沒有太多的體會(huì),Bruce Eckel 是Java的支持者,王婆賣瓜,話不能全信.個(gè)人總的感覺是,Java還是很慢,它的發(fā)展還需要時(shí)間.
上面的體會(huì)是我看了TIJ.3rdEdition.Revision4.0中第四章之后得出的,內(nèi)容和前面的有些不同.我沒有看過侯捷的中文版本,但我覺得,在關(guān)鍵問題上,原版的TIJ的確更值得一讀.所以和中文版配合起來學(xué)習(xí)是比較不錯(cuò)的選擇.
我只能算一個(gè)Java的初學(xué)者,沒想到起了這么個(gè)題目,卻受到這么多人的關(guān)注,欣喜之余,也決心盡力寫好下面的每一篇.不過這一篇完了,我就該準(zhǔn)備赴美簽證了,如果成功,那就要等到8月27號(hào)CS的研究生院開學(xué)之后,才有時(shí)間會(huì)開始研究下一章了,希望可以多從原版中獲取一點(diǎn)經(jīng)驗(yàn).
posted on 2005-12-04 11:55 Scott@JAVA 閱讀(492) 評(píng)論(0) 編輯 收藏 所屬分類: Jave SE 6