解析java記憶體配置

照編譯原理的觀點,程式運行時的記憶體配置有三種策略,分別是靜態,棧式的,和堆式的.
   靜態儲存分配是指在編譯時間就能確定每個資料目標在運行時刻的儲存空間需求,因而在編譯時間就可以給他們分配固定的記憶體空間.這種分配策略要求程式碼中
不允許有可變資料結構(比如可變數組) 的存在,也不允許有嵌套或者遞迴的結構出現,因為它們都會導致編譯器無法計算準確的儲存空間需求.
   棧式儲存分配也可稱為動態儲存裝置分配,是 由一個類似於堆棧的運行棧來實現的.和靜態儲存分配相反,在棧式儲存方案中,程式對資料區的需求在編譯時間是完全未
知的,只有到啟動並執行時候才能夠知道,但是 規定在運行中進入一個程式模組時,必須知道該程式模組所需的資料區大小才能夠為其分配記憶體.和我們在資料結構所熟
知的棧一樣,棧式儲存分配按照先進後出的 原則進行分配。
   靜態儲存分配要求在編譯時間能知道所有變數的儲存要求,棧式儲存分配要求在過程的入口處必須知道所有的儲存要求,而堆式儲存分配則專門負責在編譯時間或運
行時模組入口處都無法確定儲存要求的資料結構的記憶體配置,比如可變長度串和對象執行個體.堆由大片的可利用塊或空閑塊組成,堆中的記憶體可以按照任意順 序分配和釋放. 

堆和棧的比較
  上面的定義從編譯原理的教材中總結而來,除靜態儲存分配之外,都顯得很呆板和難以理解,下面撇開靜態儲存分配,集中比較堆和棧:
   從堆和棧的功能和作用來通俗的比較,堆主要用來存放對象的，棧主要是用來執行程式的.而這種不同又主要是由於堆和棧的特點決定的:
    在編程中，例如C/C++中，所有的方法調用都是通過棧來進行的,所有的局部變數,形式參數都是從棧中分配記憶體空間的。實際上也不是什麼分配,只是從棧頂 向上用就行,就好像工廠中的傳送帶(conveyor belt)一樣,Stack Pointer會自動指引你到放東西的位置,你所要做的只是把東西放下來就行.退出函數的時候，修改棧指標就可以把棧中的內容銷毀.這樣的模式速度最快, 當然要用來運行程式了.需要注意的是,在分配的時候,比如為一個即將 要調用的程式模組分配資料區時,應事Crowdsourced Security Testing道這個資料區的大小,也就說是雖然分配是在程式運行時進行的,但是分配的大小多少是確定的,不變的,而這個"大小 多少"是在編譯時間確定的,不是在運行時.
   堆是應用程式在啟動並執行時候請求作業系統分配給自己記憶體，由於從作業系統管理的記憶體配置,所以在分配和銷毀時都要佔用時間，因此用堆的效率非常低.但是堆的 優點在於,編譯器不必知道要從堆裡分配多少儲存空間，也不必知道儲存的資料要在堆裡停留多長的時間,因此,用堆儲存資料時會得到更大的靈活性。事實上,面 向對象的多態性,堆記憶體配置是必不可少的,因為多態變數所需的儲存空間只有在運行時建立了對象之 後才能確定.在C++中，要求建立一個對象時，只需用new命令編製相關的代碼即可。執行這些代碼時，會在堆裡自動進行資料的儲存.當然，為達到這種靈活 性，必然會付出一定的代價:在堆裡分配儲存空間時會花掉更長的時間！這也正是導致我們剛才所說的效率低的原因.

JVM中的堆和棧  
   JVM是基於堆棧的虛擬機器.JVM為每個新建立的線程都分配一個堆棧.也就是說,對於一個Java程式來說，它的運行就是通過對堆棧的操作來完成的。堆棧 以幀為單位儲存線程的狀態。JVM對堆棧只進行兩種操作:以幀為單位的壓棧和出棧操作。
   我們知道,某個線程正在執行的方法稱為此線程的當前方法.我們可能不知道,當前方法使用的幀稱為當前幀。當線程啟用一個Java方法,JVM就會線上程的 Java堆棧裡新壓入一個幀。這個幀自然成為了當前幀.在此方法執行期間,這個幀將用來儲存參數,局部變數,中間計算過程和其他資料.這個幀在這裡和編譯 原理中的活動紀錄的概念是差不多的.
  從Java的這種分配機制來看,堆棧又可以這樣理解:堆棧(Stack)是作業系統在建立某個進程時或者線程(在支援多線程的作業系統中是線程)為這個線 程建立的儲存地區，該地區具有先進後出的特性。
    每一個Java應用都唯一對應一個JVM執行個體，每一個執行個體唯一對應一個堆。應用程式在運行中所建立的所有類執行個體或數組都放在這個堆中,並由應用所有的線程 共用.跟C/C++不同，Java中分配堆記憶體是自動初始化的。Java中所有對象的儲存空間都是在堆中分配的，但是這個對象的引用卻是在堆棧中分配,也 就是說在建立一個對象時從兩個地方都分配記憶體，在堆中分配的記憶體實際建立這個對象，而在堆棧中分配的記憶體只是一個指向這個堆對象的指標(引用)而已。
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()的運行要佔用一個線程,這本身就是一個降低程式運行效能的缺陷,更何況 這個線程還要在堆中把記憶體翻來覆去的折騰.不僅如此,如上面所說,堆中存活的對象被搬移了位置,那麼所有對這些對象的引用都要重新賦值.這些開銷都會導致 效能的降低.