<Thinking in java> chapter 4
2.1 內存分配策略
按照編譯原理的觀點,程序運行時的內存分配有三種策略,分別是靜態的,棧式的,和堆式的.
靜態存儲分配是指在編譯時就能確定每個數據目標在運行時刻的存儲空間需求,因而在編譯時就可以給他們分配固定的內存空間.這種分配策略要求程序代碼中不允許有可變數據結構(比如可變數組)的存在,也不允許有嵌套或者遞歸的結構出現,因爲它們都會導致編譯程序無法計算準確的存儲空間需求.
棧式存儲分配也可稱爲動態存儲分配,是由一個類似於堆棧的運行棧來實現的.和靜態存儲分配相反,在棧式存儲方案中,程序對數據區的需求在編譯時是完全未知的,只有到運行的時候才能夠知道,但是規定在運行中進入一個程序模塊時,必須知道該程序模塊所需的數據區大小才能夠爲其分配內存.和我們在數據結構所熟知的棧一樣,棧式存儲分配按照先進後出的原則進行分配。
靜態存儲分配要求在編譯時能知道所有變量的存儲要求,棧式存儲分配要求在過程的入口處必須知道所有的存儲要求,而堆式存儲分配則專門負責在編譯時或運行時模塊入口處都無法確定存儲要求的數據結構的內存分配,比如可變長度串和對象實例.堆由大片的可利用塊或空閒塊組成,堆中的內存可以按照任意順序分配和釋放.
2.2 堆和棧的比較
上面的定義從編譯原理的教材中總結而來,除靜態存儲分配之外,都顯得很呆板和難以理解,下面撇開靜態存儲分配,集中比較堆和棧:
從堆和棧的功能和作用來通俗的比較,堆主要用來存放對象的，棧主要是用來執行程序的.而這種不同又主要是由於堆和棧的特點決定的:
在編程中，例如C/C++中，所有的方法調用都是通過棧來進行的,所有的局部變量,形式參數都是從棧中分配內存空間的。實際上也不是什麼分配,只是從棧頂向上用就行,就好像工廠中的傳送帶(conveyor belt)一樣,Stack Pointer會自動指引你到放東西的位置,你所要做的只是把東西放下來就行.退出函數的時候，修改棧指針就可以把棧中的內容銷燬.這樣的模式速度最快,當然要用來運行程序了.需要注意的是,在分配的時候,比如爲一個即將要調用的程序模塊分配數據區時,應事先知道這個數據區的大小,也就說是雖然分配是在程序運行時進行的,但是分配的大小多少是確定的,不變的,而這個"大小多少"是在編譯時確定的,不是在運行時.
堆是應用程序在運行的時候請求操作系統分配給自己內存，由於從操作系統管理的內存分配,所以在分配和銷燬時都要佔用時間，因此用堆的效率非常低.但是堆的優點在於,編譯器不必知道要從堆裏分配多少存儲空間，也不必知道存儲的數據要在堆裏停留多長的時間,因此,用堆保存數據時會得到更大的靈活性。事實上,面向對象的多態性,堆內存分配是必不可少的,因爲多態變量所需的存儲空間只有在運行時創建了對象之後才能確定.在C++中，要求創建一個對象時，只需用new命令編制相關的代碼即可。執行這些代碼時，會在堆裏自動進行數據的保存.當然，爲達到這種靈活性，必然會付出一定的代價:在堆裏分配存儲空間時會花掉更長的時間！這也正是導致我們剛纔所說的效率低的原因,看來列寧同志說的好,人的優點往往也是人的缺點,人的缺點往往也是人的優點(暈~).
2.3 JVM中的堆和棧
JVM是基於堆棧的虛擬機.JVM爲每個新創建的線程都分配一個堆棧.也就是說,對於一個Java程序來說，它的運行就是通過對堆棧的操作來完成的。堆棧以幀爲單位保存線程的狀態。JVM對堆棧只進行兩種操作:以幀爲單位的壓棧和出棧操作。
我們知道,某個線程正在執行的方法稱爲此線程的當前方法.我們可能不知道,當前方法使用的幀稱爲當前幀。當線程激活一個Java方法,JVM就會在線程的Java堆棧裏新壓入一個幀。這個幀自然成爲了當前幀.在此方法執行期間,這個幀將用來保存參數,局部變量,中間計算過程和其他數據.這個幀在這裏和編譯原理中的活動紀錄的概念是差不多的.
從Java的這種分配機制來看,堆棧又可以這樣理解:堆棧(Stack)是操作系統在建立某個進程時或者線程(在支持多線程的操作系統中是線程)爲這個線程建立的存儲區域，該區域具有先進後出的特性。
每一個Java應用都唯一對應一個JVM實例，每一個實例唯一對應一個堆。應用程序在運行中所創建的所有類實例或數組都放在這個堆中,並由應用所有的線程共享.跟C/C++不同，Java中分配堆內存是自動初始化的。Java中所有對象的存儲空間都是在堆中分配的，但是這個對象的引用卻是在堆棧中分配,也就是說在建立一個對象時從兩個地方都分配內存，在堆中分配的內存實際建立這個對象，而在堆棧中分配的內存只是一個指向這個堆對象的指針(引用)而已。
2.4 GC的思考
Java爲什麼慢?JVM的存在當然是一個原因,但有人說,在Java中,除了簡單類型(int,char等)的數據結構,其它都是在堆中分配內存(所以說Java的一切都是對象)，這也是程序慢的原因之一。
我的想法是(應該說代表TIJ的觀點),如果沒有Garbage Collector(GC),上面的說法就是成立的.堆不象棧是連續的空間,沒有辦法指望堆本身的內存分配能夠象堆棧一樣擁有傳送帶般的速度,因爲,誰會爲你整理龐大的堆空間,讓你幾乎沒有延遲的從堆中獲取新的空間呢?
這個時候,GC站出來解決問題.我們都知道GC用來清除內存垃圾,爲堆騰出空間供程序使用,但GC同時也擔負了另外一個重要的任務,就是要讓Java中堆的內存分配和其他語言中堆棧的內存分配一樣快,因爲速度的問題幾乎是衆口一詞的對Java的詬病.要達到這樣的目的,就必須使堆的分配也能夠做到象傳送帶一樣,不用自己操心去找空閒空間.這樣,GC除了負責清除Garbage外,還要負責整理堆中的對象,把它們轉移到一個遠離Garbage的純淨空間中無間隔的排列起來,就象堆棧中一樣緊湊,這樣Heap Pointer就可以方便的指向傳送帶的起始位置,或者說一個未使用的空間,爲下一個需要分配內存的對象"指引方向".因此可以這樣說,垃圾收集影響了對象的創建速度,聽起來很怪,對不對?
那GC怎樣在堆中找到所有存活的對象呢?前面說了,在建立一個對象時，在堆中分配實際建立這個對象的內存,而在堆棧中分配一個指向這個堆對象的指針(引用),那麼只要在堆棧(也有可能在靜態存儲區)找到這個引用,就可以跟蹤到所有存活的對象.找到之後,GC將它們從一個堆的塊中移到另外一個堆的塊中,並將它們一個挨一個的排列起來,就象我們上面說的那樣,模擬出了一個棧的結構,但又不是先進後出的分配,而是可以任意分配的,在速度可以保證的情況下,Isn't it great?
但是，列寧同志說了,人的優點往往也是人的缺點,人的缺點往往也是人的優點(再暈~~).GC()的運行要佔用一個線程,這本身就是一個降低程序運行性能的缺陷,更何況這個線程還要在堆中把內存翻來覆去的折騰.不僅如此,如上面所說,堆中存活的對象被搬移了位置,那麼所有對這些對象的引用都要重新賦值.這些開銷都會導致性能的降低.
此消彼長,GC()的優點帶來的效益是否蓋過了它的缺點導致的損失,我也沒有太多的體會,Bruce Eckel 是Java的支持者，王婆賣瓜，話不能全信.個人總的感覺是,Java還是很慢,它的發展還需要時間.
上面的體會是我看了TIJ.3rdEdition.Revision4.0中第四章之後得出的,內容和前面的有些不同.我沒有看過侯捷的中文版本,但我覺得,在關鍵問題上,原版的TIJ的確更值得一讀.所以和中文版配合起來學習是比較不錯的選擇.
我只能算一個Java的初學者,沒想到起了這麼個題目,卻受到這麼多人的關注,欣喜之餘,也決心盡力寫好下面的每一篇.不過這一篇完了,我就該準備赴美簽證了,如果成功,那就要等到8月27號CS的研究生院開學之後,纔有時間會開始研究下一章了,希望可以多從原版中獲取一點經驗.
棧和堆都是在RAM區中分配空間的；
棧能夠通過系統中的一個指針移動來存儲讀寫，既指針移動就能pop或者push，所以它的速度比較快。但只適合於那些大小和生命週期已經知道的東東。一般對象引用存放在該區，但對象本身不放在該區。
堆適合於那些大小和生命週期不知道的東東，系統不需要了解，這樣靈活性大，但是花費時間要更多一些。一般java對象本身放在該區。