????????序言：Java與C++之間有一堵由內存動態分配和垃圾收集技術所圍成的高墻，墻外面的人想進去，墻里面的人卻想出來。

1.1概述

????????對于從事C、C++程序開發的開發人員來說，在內存管理領域，他們既是擁有最高權力的“皇帝”，又是從事最基礎工作的勞動人民——既擁有每一個對象的“所有權”，又擔負著每一個對象生命從開始到終結的維護責任。對于Java程序員來說，在虛擬機自動內存管理機制的幫助下，不再需要為每一個new操作去寫配對的delete/free代碼，不容易出現內存泄漏和內存溢出問題，看起來由虛擬機管理內存一切都很美好。不過，也正是因為Java程序員把控制內存的權力交給了Java虛擬機，一旦出現內存泄漏和溢出方面的問題，如果不了解虛擬機是怎樣使用內存的，那排查錯誤、修正問題將會成為一項異常艱難的工作。

1.2運行時數據區域

???????Java虛擬機在執行Java程序的過程中會把它所管理的內存劃分為若干個不同的數據區域。這些區域有各自的用途，以及創建和銷毀的時間，有的區域隨著虛擬機進程的啟動而一直存在，有些區域則是依賴用戶線程的啟動和結束而建立和銷毀。根據《Java虛擬機規范》的規定，Java虛擬機所管理的內存將會包括以下幾個運行時數據區域，如圖所示。

1.2.1程序計數器

???????程序計數器(Program Counter Register)是一塊較小的內存空間，它可以看作是當前線程所執行的字節碼的行號指示器。在Java虛擬機的概念模型里，字節碼解釋器工作時就是通過改變這個計數器的值來選取下一條需要執行的字節碼指令，它是程序控制流的指示器，分支、循環、跳轉、異常處理、線程恢復等基礎功能都需要依賴這個計數器來完成。由于Java虛擬機的多線程是通過線程輪流切換、分配處理器執行時間的方式來實現的，在任何一個確定的時刻，一個處理器（對于多核處理器來說是一個內核）都只會執行一條線程中的指令。因此，為了線程切換后能恢復到正確的執行位置，每條線程都需要有一個獨立的程序計數器，各條線程之間計數器互不影響，獨立存儲，我們稱這類內存區域為“線程私有”的內存。如果線程正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機字節碼指令的地址；如果正在執行的是本地(Native)方法，這個計數器值則應為空(Undefined)。此內存區域是唯一一個在《Java虛擬機規范》中沒有規定任何OutOfMemoryError情況的區域。?

1.2.2?Java虛擬機棧

????????與程序計數器一樣，Java虛擬機棧(Java Virtual Machine Stack)也是線程私有的，它的生命周期與線程相同。虛擬機棧描述的是Java方法執行的線程內存模型：每個方法被執行的時候，Java虛擬機都會同步創建一個棧幀(Stack Frame)用于存儲局部變量表、操作數棧、動態連接、方法出口等信息。每一個方法被調用直至執行完畢的過程，就對應著一個棧幀在虛擬機棧中從入棧到出棧的過程。經常有人把Java內存區域籠統地劃分為堆內存(Heap)和棧內存(Stack)，這種劃分方式直接繼承自傳統的C、C++程序的內存布局結構，在Java語言里就顯得有些粗糙了，實際的內存區域劃分要比這更復雜。不過這種劃分方式的流行也間接說明了程序員最關注的、與對象內存分配關系最密切的區域是“堆”和“棧”兩塊。其中，“堆”在稍后專門講述，而“棧”通常就是指這里講的虛擬機棧，或者更多的情況下只是指虛擬機棧中局部變量表部分。

????????局部變量表存放了編譯期可知的各種Java虛擬機基本數據類型(boolean、byte、char、short、int、float、long、double)、對象引用（reference類型，它并不等同于對象本身，可能是一個指向對象起始地址的引用指針，也可能是指向一個代表對象的句柄或者其他與此對象相關的位置）和returnAddress類型（指向了一條字節碼指令的地址）。這些數據類型在局部變量表中的存儲空間以局部變量槽(Slot)來表示，其中64位長度的long和double類型的數據會占用兩個變量槽，其余的數據類型只占用一個。局部變量表所需的內存空間在編譯期間完成分配，當進入一個方法時，這個方法需要在棧幀中分配多大的局部變量空間是完全確定的，在方法運行期間不會改變局部變量表的大小。請讀者注意，這里說的“大小”是指變量槽的數量，虛擬機真正使用多大的內存空間（譬如按照1個變量槽占用32個比特、64個比特，或者更多）來實現一個變量槽，這是完全由具體的虛擬機實現自行決定的事情。

????????在《Java虛擬機規范》中，對這個內存區域規定了兩類異常狀況：如果線程請求的棧深度大于虛擬機所允許的深度，將拋出StackOverflowError異常；如果Java虛擬機棧容量可以動態擴展，當棧擴展時無法申請到足夠的內存會拋出OutOfMemoryError異常。

1.2.3本地方法棧

????????本地方法棧(Native Method Stacks)與虛擬機棧所發揮的作用是非常相似的，其區別只是虛擬機棧為虛擬機執行Java方法（也就是字節碼）服務，而本地方法棧則是為虛擬機使用到的本地(Native)方法服務。《Java虛擬機規范》對本地方法棧中方法使用的語言、使用方式與數據結構并沒有任何強制規定，因此具體的虛擬機可以根據需要自由實現它，甚至有的Java虛擬機（譬如Hot-Spot虛擬機）直接就把本地方法棧和虛擬機棧合二為一。與虛擬機棧一樣，本地方法棧也會在棧深度溢出或者棧擴展失敗時分別拋出StackOverflowError和OutOfMemoryError異常。

1.2.4Java堆

????????對于Java應用程序來說，Java堆(Java Heap)是虛擬機所管理的內存中最大的一塊。Java堆是被所有線程共享的一塊內存區域，在虛擬機啟動時創建。此內存區域的唯一目的就是存放對象實例，Java世界里“幾乎”所有的對象實例都在這里分配內存。在《Java虛擬機規范》中對Java堆的描述是：“所有的對象實例以及數組都應當在堆上分配”，而這里筆者寫的“幾乎”是指從實現角度來看，隨著Java語言的發展，現在已經能看到些許跡象表明日后可能出現值類型的支持，即使只考慮現在，由于即時編譯技術的進步，尤其是逃逸分析技術的日漸強大，棧上分配、標量替換優化手段已經導致一些微妙的變化悄然發生，所以說Java對象實例都分配在堆上也漸漸變得不是那么絕對了。

????????Java堆是垃圾收集器管理的內存區域，因此一些資料中它也被稱作“GC堆”（Garbage Collected Heap，幸好國內沒翻譯成“垃圾堆”）。從回收內存的角度看，由于現代垃圾收集器大部分都是基于分代收集理論設計的，所以Java堆中經常會出現“新生代”“老年代”“永久代”“Eden空間”“From Survivor空間”“To Survivor空間”等名詞，這些概念在本書后續章節中還會反復登場亮相，在這里筆者想先說明的是這些區域劃分僅僅是一部分垃圾收集器的共同特性或者說設計風格而已，而非某個Java虛擬機具體實現的固有內存布局，更不是《Java虛擬機規范》里對Java堆的進一步細致劃分。不少資料上經常寫著類似于“Java虛擬機的堆內存分為新生代、老年代、永久代、Eden、Survivor……”這樣的內容。在十年之前（以G1收集器的出現為分界），作為業界絕對主流的HotSpot虛擬機，它內部的垃圾收集器全部都基于“經典分代”[插圖]來設計，需要新生代、老年代收集器搭配才能工作，在這種背景下，上述說法還算是不會產生太大歧義。但是到了今天，垃圾收集器技術與十年前已不可同日而語，HotSpot里面也出現了不采用分代設計的新垃圾收集器，再按照上面的提法就有很多需要商榷的地方了。

????????如果從分配內存的角度看，所有線程共享的Java堆中可以劃分出多個線程私有的分配緩沖區(Thread Local Allocation Buffer，TLAB)，以提升對象分配時的效率。不過無論從什么角度，無論如何劃分，都不會改變Java堆中存儲內容的共性，無論是哪個區域，存儲的都只能是對象的實例，將Java堆細分的目的只是為了更好地回收內存，或者更快地分配內存。在本章中，我們僅僅針對內存區域的作用進行討論，Java堆中的上述各個區域的分配、回收等細節將會是下一篇的主題。

????????根據《Java虛擬機規范》的規定，Java堆可以處于物理上不連續的內存空間中，但在邏輯上它應該被視為連續的，這點就像我們用磁盤空間去存儲文件一樣，并不要求每個文件都連續存放。但對于大對象（典型的如數組對象），多數虛擬機實現出于實現簡單、存儲高效的考慮，很可能會要求連續的內存空間。Java堆既可以被實現成固定大小的，也可以是可擴展的，不過當前主流的Java虛擬機都是按照可擴展來實現的（通過參數-Xmx和-Xms設定）。如果在Java堆中沒有內存完成實例分配，并且堆也無法再擴展時，Java虛擬機將會拋出OutOfMemoryError異常。