http://developer.51cto.com/col/1006/
在JVM中，內存分爲兩個部分，Stack（棧）和Heap（堆），這裏，我們從JVM的內存管理原理的角度來認識Stack和Heap，並通過這些原理認清Java中靜態方法和靜態屬性的問題。
一般，JVM的內存分爲兩部分：Stack和Heap。
Stack（棧）是JVM的內存指令區。Stack管理很簡單，push一定長度字節的數據或者指令，Stack指針壓棧相應的字節位移；pop一定字節長度數據或者指令，Stack指針彈棧。Stack的速度很快，管理很簡單，並且每次操作的數據或者指令字節長度是已知的。所以Java 基本數據類型，Java 指令代碼，常量都保存在Stack中。
Heap（堆）是JVM的內存數據區。Heap 的管理很複雜，每次分配不定長的內存空間，專門用來保存對象的實例。在Heap 中分配一定的內存來保存對象實例，實際上也只是保存對象實例的屬性值，屬性的類型和對象本身的類型標記等，並不保存對象的方法（方法是指令，保存在Stack中）,在Heap 中分配一定的內存保存對象實例和對象的序列化比較類似。而對象實例在Heap 中分配好以後，需要在Stack中保存一個4字節的Heap 內存地址，用來定位該對象實例在Heap 中的位置，便於找到該對象實例。
由於Stack的內存管理是順序分配的，而且定長，不存在內存回收問題；而Heap 則是隨機分配內存，不定長度，存在內存分配和回收的問題；因此在JVM中另有一個GC進程，定期掃描Heap ，它根據Stack中保存的4字節對象地址掃描Heap ，定位Heap 中這些對象，進行一些優化（例如合併空閒內存塊什麼的），並且假設Heap 中沒有掃描到的區域都是空閒的，統統refresh（實際上是把Stack中丟失了對象地址的無用對象清除了），這就是垃圾收集的過程；關於垃圾收集的更深入講解請參考51CTO之前的文章《JVM內存模型及垃圾收集策略解析》。
JVM的體系結構
我們首先要搞清楚的是什麼是數據以及什麼是指令。然後要搞清楚對象的方法和對象的屬性分別保存在哪裏。
1）方法本身是指令的操作碼部分，保存在Stack中；
2）方法內部變量作爲指令的操作數部分，跟在指令的操作碼之後，保存在Stack中（實際上是簡單類型保存在Stack中，對象類型在Stack中保存地址，在Heap 中保存值）；上述的指令操作碼和指令操作數構成了完整的Java 指令。
3）對象實例包括其屬性值作爲數據，保存在數據區Heap 中。
非靜態的對象屬性作爲對象實例的一部分保存在Heap 中，而對象實例必須通過Stack中保存的地址指針才能訪問到。因此能否訪問到對象實例以及它的非靜態屬性值完全取決於能否獲得對象實例在Stack中的地址指針。
非靜態方法和靜態方法的區別：
非靜態方法有一個和靜態方法很重大的不同：非靜態方法有一個隱含的傳入參數，該參數是JVM給它的，和我們怎麼寫代碼無關，這個隱含的參數就是對象實例在Stack中的地址指針。因此非靜態方法（在Stack中的指令代碼）總是可以找到自己的專用數據（在Heap 中的對象屬性值）。當然非靜態方法也必須獲得該隱含參數，因此非靜態方法在調用前，必須先new一個對象實例，獲得Stack中的地址指針，否則JVM將無法將隱含參數傳給非靜態方法。
靜態方法無此隱含參數，因此也不需要new對象，只要class文件被ClassLoader load進入JVM的Stack，該靜態方法即可被調用。當然此時靜態方法是存取不到Heap 中的對象屬性的。
總結一下該過程：當一個class文件被ClassLoader load進入JVM後，方法指令保存在Stack中，此時Heap 區沒有數據。然後程序技術器開始執行指令，如果是靜態方法，直接依次執行指令代碼，當然此時指令代碼是不能訪問Heap 數據區的；如果是非靜態方法，由於隱含參數沒有值，會報錯。因此在非靜態方法執行前，要先new對象，在Heap 中分配數據，並把Stack中的地址指針交給非靜態方法，這樣程序技術器依次執行指令，而指令代碼此時能夠訪問到Heap 數據區了。
靜態屬性和動態屬性：
前面提到對象實例以及動態屬性都是保存在Heap 中的，而Heap 必須通過Stack中的地址指針才能夠被指令（類的方法）訪問到。因此可以推斷出：靜態屬性是保存在Stack中的，而不同於動態屬性保存在Heap 中。正因爲都是在Stack中，而Stack中指令和數據都是定長的，因此很容易算出偏移量，也因此不管什麼指令（類的方法），都可以訪問到類的靜態屬性。也正因爲靜態屬性被保存在Stack中，所以具有了全局屬性。
在JVM中，靜態屬性保存在Stack指令內存區，動態屬性保存在Heap數據內存區。
2.3 JVM的垃圾收集策略
GC的執行時要耗費一定的CPU資源和時間的，因此在JDK1.2以後，JVM引入了分代收集的策略，其中對新生代採用"Mark-Compact"策略，而對老生代採用了“Mark-Sweep"的策略。其中新生代的垃圾收集器命名爲“minor gc”，老生代的GC命名爲"Full Gc 或者Major GC".其中用System.gc()強制執行的是Full Gc.
2.3.1 Serial Collector
Serial Collector是指任何時刻都只有一個線程進行垃圾收集，這種策略有一個名字“stop the whole world",它需要停止整個應用的執行。這種類型的收集器適合於單CPU的機器。
Serial Copying Collector
此種GC用-XX:UseSerialGC選項配置，它只用於新生代對象的收集。1.5.0以後。-XX:MaxTenuringThreshold來設置對象複製的次數。當eden空間不夠的時候，GC會將eden的活躍對象和一個名叫From survivor空間中尚不夠資格放入Old代的對象複製到另外一個名字叫To Survivor的空間。而此參數就是用來說明到底From survivor中的哪些對象不夠資格，假如這個參數設置爲31，那麼也就是說只有對象複製31次以後纔算是有資格的對象。這裏需要注意幾個個問題：
◆ From Survivor和To survivor的角色是不斷的變化的，同一時間只有一塊空間處於使用狀態，這個空間就叫做From Survivor區，當複製一次後角色就發生了變化。
◆ 如果複製的過程中發現To survivor空間已經滿了，那麼就直接複製到old generation.
◆ 比較大的對象也會直接複製到Old generation,在開發中，我們應該儘量避免這種情況的發生。
Serial Mark-Compact Collector
串行的標記-整理收集器是JDK5 update6之前默認的老生代的垃圾收集器，此收集使得內存碎片最少化，但是它需要暫停的時間比較長。
2.3.2 Parallel Collector
Parallel Collector主要是爲了應對多CPU，大數據量的環境。Parallel Collector又可以分爲以下兩種：
Parallel Copying Collector
此種GC用-XX:UseParNewGC參數配置,它主要用於新生代的收集,此GC可以配合CMS一起使用。1.4.1以後Parallel Mark-Compact Collector，此種GC用-XX:UseParallelOldGC參數配置，此GC主要用於老生代對象的收集。1.6.0
Parallel scavenging Collector
此種GC用-XX:UseParallelGC參數配置，它是對新生代對象的垃圾收集器，但是它不能和CMS配合使用，它適合於比較大新生代的情況，此收集器起始於jdk 1.4.0。它比較適合於對吞吐量高於暫停時間的場合，Serial gc和Parallel gc可以用如下的圖來表示：
2.3.3 Concurrent Collector
Concurrent Collector通過並行的方式進行垃圾收集，這樣就減少了垃圾收集器收集一次的時間，這種GC在實時性要求高於吞吐量的時候比較有用。此種GC可以用參數-XX:UseConcMarkSweepGC配置，此GC主要用於老生代和Perm代的收集。
