按照編譯原理的觀點,程式執行時的記憶體分配有三種策略,分別是靜態的,棧式的,和堆式的.
靜態儲存分配是指在編譯時就能確定每個資料目標在執行時刻的儲存空間需求,因而在編譯時就可以給他們分配固定的記憶體空間.這種分配策略要求程式程式碼中不允許有可變資料結構(比如可變陣列)的存在,也不允許有巢狀或者遞迴的結構出現,因為它們都會導致編譯程式無法計算準確的儲存空間需求.

        棧式儲存分配也可稱為動態儲存分配,是由一個類似於堆疊的執行棧來實現的.和靜態儲存分配相反,在棧式儲存方案中,程式對資料區的需求在編譯時是完全未知的,只有到執行的時候才能夠知道,但是規定在執行中進入一個程式模組時,必須知道該程式模組所需的資料區大小才能夠為其分配記憶體.和我們在資料結構所熟知的棧一樣,棧式儲存分配按照先進後出的原則進行分配。

       靜態儲存分配要求在編譯時能知道所有變數的儲存要求,棧式儲存分配要求在過程的入口處必須知道所有的儲存要求,而堆式儲存分配則專門負責在編譯時或執行時模組入口處都無法確定儲存要求的資料結構的記憶體分配,比如可變長度串和物件例項.堆由大片的可利用塊或空閒塊組成,堆中的記憶體可以按照任意順序分配和釋放.

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還是很慢,它的發展還需要時間.