1. 執行時資料區
Java虛擬機器在執行Java程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些區域有各自的用途，建立和以及銷燬的時間，有的區域隨著虛擬機器程序的啟動而一直存在，有的區域則是依賴使用者執行緒的啟動結束而建立和銷燬。
1.1 程式計數器（執行緒私有）
程式計數器(Program Counter Register)是一塊較小的記憶體空間，它可以看作是當前執行緒所執行的位元組碼的行號指示器。在Java虛擬機器的概念模型裡，位元組碼直譯器工作時就是透過改變這個計數器的值來選取下一條需要執行的位元組碼指令，它是程式控制流的指示器，分支、迴圈、跳轉、異常處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。
由於Java虛擬機器的多執行緒是透過執行緒輪流切換、分配處理器執行時間的方式來實現的在任何一個確定的時刻，一個處理器(對於多核處理器來說是一個核心)都只會執行一條執行緒中的指令。因此，為了執行緒切換後能恢復到正確的執行位置，每條執行緒都需要有一個獨立的程式計數器，各條執行緒之間計數器互不影響，獨立儲存，所以該區域為“執行緒私有”。
如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是本地(Native)方法，這個計數器值則應為空(Undefined)。此記憶體區域是唯一一個在《Java虛擬機器規範》中沒有規定任何Out Of Memory Error 情況的區域。
1.2 java虛擬機器棧（執行緒私有）
Java 虛擬機器棧的生命週期與執行緒相同。
虛擬機器棧描述的是Java方法執行的執行緒記憶體模型：每個方法被執行的時候，Java虛擬機器都會同步建立一個棧幀用於儲存區域性變數表、運算元棧、動態連線、方法出口等資訊。每一個方法被呼叫直至執行完畢的過程，就對應著一個棧幀在虛擬機器棧中從人棧到出棧的過程。
Java 虛擬機器棧通常儲存著我們最關注的區域性變數表。區域性變數表存放了編譯期可知的各種Java虛擬機器基本資料型別(boolean、byte、char、short、int、float、long、double)、物件引用(reference型別，它並不等同於物件本身，可能是一個指向物件起始地址的引用指標，也可能是指向一個代表物件的控制代碼或者其他與此物件相關的位置)和returnAddress型別(指向了一條位元組碼指令的地址)。
這些資料型別在區域性變數表中的儲存空間以區域性變數槽(Slot)來表示，其中64位長度的long 和 double 型別的資料會佔用兩個變數槽，其餘的資料型別只佔用一個。區域性變數表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在棧幀中分配多大的區域性變數空間是完全確定的，在方法執行期間不會改變區域性變數表的大小（主要指槽的數量）。
如果執行緒請求的棧深度大於虛擬機器所允許的深度，將丟擲Stack Over flow Error異常；如果Java虛擬機器棧容量可以動態擴充套件，當棧擴充套件時無法申請到足夠的記憶體會丟擲Out Of Memory Error 異常。
1.3 本地方法棧（執行緒私有）
本地方法棧與虛擬機器棧所發揮的作用是非常相似的，其區別只是虛擬機器棧為虛擬機器執行Java方法(也就是位元組碼)服務，而本地方法棧則是為虛擬機器使用到的本地(Native)方法服務。
與虛擬機器棧一樣，本地方法棧也會在棧深度溢位或者棧擴充套件失敗時分別丟擲Stack Over flow Error和Out Of Memory Error 異常
1.4 堆（執行緒共享）
對於Java應用程式來說，Java堆(Java Heap)是虛擬機器所管理的記憶體中最大的一塊。Java堆是被所有執行緒共享的一塊記憶體區域，在虛擬機器啟動時建立。此記憶體區域的唯一目的就是存放物件例項。Java世界裡“幾乎”所有的物件例項都在這裡分配記憶體。
Java堆是垃圾收集器管理的記憶體區域，因此它也被稱作“GC堆”。從回收記憶體的角度看，由於現代垃圾收集器大部分都是基於分代收集理論設計的，所以Java堆中經常會出現“新生代”“老年代”“永久代”“ Eden 空間”“From Survivor 空間”“To Survivor 空間”等名詞，但是在G1收集器的出現之前，作為業界絕對主流的HotSpot虛擬機器，它內部的垃圾收集器全部都基於“經典分代”來設計，需要新生代、老年代收集器搭配才能工作。但是到了今天，HotSpot裡面也出現了不採用分代設計的新垃圾收集器。
如果從分配記憶體的角度看，所有執行緒共享的Java堆中可以劃分出多個執行緒私有的分配緩衝區(Thread Local Allocation Buffer，TLAB)，以提升物件分配時的效率。不過無論從什麼角度，無論如何劃分，都不會改變Java堆中儲存內容的共性，無論是哪個區域，儲存的都只能是物件的例項，將Java堆細分的目的只是為了更好地回收記憶體，或者更快地分配記憶體。
Java堆既可以被實現成固定大小的，也可以是可擴充套件的，不過當前主流的Java虛擬機器都是按照可擴充套件來實現的(透過引數-Xmx和-Xms設定)。如果在Java堆中沒有記憶體完成例項分配，並且堆也無法再擴充套件時，Java虛擬機器將會丟擲Out Of Memory Error 異常。
1.5 方法區（執行緒共享）
方法區用於儲存已被虛擬機器載入的型別資訊、常量、靜態變數、即時編譯器編譯後的程式碼快取等資料。
“永久代”和方法區。本質上這兩者並不是等價的，永久代可以看作是方法區的實現。到了JDK7的 HotSpot，已經把原本放在永久代的字串常量池、靜態變數等移出，而到了JDK8，完全廢棄了永久代的概念，改用使用元空間(Meta-space)來代替，把JDK7中永久代還剩餘的內容(主要是型別資訊)全部移到元空間中。
如果方法區無法滿足新的記憶體分配需求時，將丟擲Out Of Memory Error 異常。
執行時常量池是方法區的一部分。Class 檔案中除了有類的版本、欄位、方法、介面等描述資訊外，還有一項資訊是常量池表(Constant Pool Table)，用於存放編譯期生成的各種字面量與符號引用，這部分內容將在類載入後存放到方法區的執行時常量池中。
既然執行時常量池是方法區的一部分，自然受到方法區記憶體的限制，當常量池無法再申請到記憶體時會丟擲
Out Of Memory Error異常。
2. 物件
2.1 物件的建立
當Java虛擬機器遇到一條位元組碼new指令時，首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已被載入、解析和初始化過。如果沒有，那必須先執行相應的類載入過程。
在類載入檢查透過後，接下來虛擬機器將為新生物件分配記憶體。物件所需記憶體的大小在類載入完成後便可完全確定，為物件分配空間的任務實際上便等同於把一塊確定大小的記憶體塊從Java堆中劃分出來。
假設Java堆中記憶體是絕對規整的，所有被使用過的記憶體都被放在一邊，空閒的記憶體被放在另一邊，中間放著一個指標作為分界點的指示器，那所分配記憶體就僅僅是把那個指標向空閒空間方向挪動一段與物件大小相等的距離，這種分配方式稱為“指標碰撞”(BumpThePointer)。
如果Java堆中的記憶體並不是規整的，已被使用的記憶體和空閒的記憶體相互交錯在一起，那就沒有辦法簡單地進行指標碰撞了，虛擬機器就必須維護一個列表，記錄上哪些記憶體塊是可用的，在分配的時候，從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式稱為“空閒列表”(Free List)。
選擇哪種分配方式由Java堆是否規整決定，而Java堆是否規整又由所採用的垃圾收集器是否帶有空間壓縮整理(Compact)的能力決定。因此，當使用Serial、ParNew等帶壓縮整理過程的收集器時，系統採用的分配演算法是指標碰撞，既簡單又高效；而當使用CMS這種基於清除(Sweep)演算法的收集器時，理論上就只能採用較為複雜的空閒列表來分配記憶體。
物件建立在虛擬機器中是非常頻繁的行為，即使僅僅修改一個指標所指向的位置，在併發情況下也並不是執行緒安全的，可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體的情況。解決這個問題有兩種可選方案：一種是對分配記憶體空間的動作進行同步處理--實際上虛擬機器是採用CAS配上失敗重試的方式保證更新操作的原子性；另外一種是把記憶體分配的動作按照執行緒劃分在不同的空間之中進行，即每個執行緒在Java堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝(Thread Local Allocation Buffer，TLAB)。哪個執行緒要分配記憶體、就在哪個執行緒的本地緩衝區中分配，只有本地緩衝區用完了，分配新的快取區時才需要同步鎖定。虛擬機器是否使用TLAB，可以透過-XX:+/-UseTLAB引數來設定。
記憶體分配完成之後，虛擬機器必須將分配到的記憶體空間(但不包括物件頭)都初始化為零值，如果使用了TLAB的話，這一項工作也可以提前至TLAB分配時順便進行。這步操作保證了物件的例項欄位在Java程式碼中可以不賦初始值就直接使用，訪問到的是這些欄位的資料型別所對應的零值。
接下來，Java虛擬機器還要對物件進行必要的設定，例如這個物件是哪個類的例項，如何才能找到類的後設資料資訊、物件的雜湊碼(實際上物件的雜湊碼會延後到真正呼叫Object.hashCode( )方法時才計算)、物件的GC分代年齡等資訊。這些資訊存放在物件的物件頭(Object Header)之中。根據虛擬機器當前執行狀態的不同，如是否啟用偏向鎖等，物件頭會有不同的設定方式。
在上面工作都完成之後，從虛擬機器的視角來看，一個新的物件已經產生了。但是從Java程式的視角看來，物件建立才剛剛開始----建構函式，即Class檔案中的
2.2 物件的記憶體佈局
在HotSpot虛擬機器裡，物件在堆記憶體中的儲存佈局可以劃分為三個部分:物件頭(Header)，例項資料(Instance Data)和對齊填充(Padding)。
HotSpot虛擬機器物件的物件頭部分包括兩類資訊。第一類是用於儲存物件自身的執行時資料，如雜湊碼、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID，偏向時間戳等，這部分資料的長度在32位和64位的虛擬機器(未開啟壓縮指標)中分別為32個位元和64個位元，官方稱它為“Mark Word”。物件需要儲存的執行時資料很多，其實已經超出了32、64位Bitmap結構所能記錄的最大限度，但物件頭裡的資訊是與物件自身定義的資料無關的額外儲存成本，考慮到虛擬機器的空間效率，Mark Word被設計成一個有著動態定義的資料結構，以便在極小的空間記憶體儲儘量多的資料，根據物件的狀態複用自己的儲存空間。例如在32位的HotSpot虛擬機器中，如物件未被同步鎖鎖定的狀態下Mark Word的32個位元儲存空間中的25個位元用於儲存物件雜湊碼，4個位元用於儲存物件分代年齡，2個位元用於儲存鎖標誌位，1個位元固定為0，在其他狀態(輕量級鎖定重量級鎖定、GC標記、可偏向)下物件的儲存內容如表所示。
| 儲存內容 | 標誌位 | 狀態 |
|---|---|---|
| 物件雜湊碼，物件分代年齡 | 01 | 未鎖定 |
| 指向所記錄的指標 | 00 | 輕量級鎖定 |
| 指向重量級鎖的指標 | 10 | 膨脹，重量級鎖定 |
| 空，不記錄資訊 | 11 | GC標記 |
| 偏向執行緒id，偏向時間戳，物件分代年齡 | 01 | 可偏向 |
物件頭的另外一部分是型別指標，即物件指向它的型別後設資料的指標，Java虛擬機器通這個指標來確定該物件是哪個類的例項。並不是所有的虛擬機器實現都必須在物件資料上保留型別指標，換句話說，查詢物件的後設資料資訊並不一定要經過物件本身。此外，如果物件是一個Java陣列，那在物件頭中還必須有一塊用於記陣列長度的資料，因為虛擬機器可以透過普通Java物件的後設資料資訊確定Java物件的大小，但是如果陣列的長度是不確定的，將無法透過後設資料中的資訊推斷出陣列的大小。
接下來例項資料部分是物件真正儲存的有效資訊，即我們在程式程式碼裡面所定義的各種型別的欄位內容，無論是從父類繼承下來的，還是在子類中定義的欄位。
物件的第三部分是對齊填充，這並不是必然存在的，也沒有特別的含義，它僅僅起著佔位符的作用。
2.3 物件的訪問定位
建立物件自然是為了後續使用該物件，我們的Java程式會透過棧上的reference 資料來操作堆上的具體物件。reference 型別是一個指向物件的引用，實現方式主要有使用控制代碼和直接指標兩種:
- 如果使用控制代碼訪問的話，Java堆中將可能會劃分出一塊記憶體來作為控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件例項資料與型別資料各自具體的地址資訊。
- 如果使用直接指標訪問的話，Java堆中物件的記憶體佈局就必須考慮如何放置訪問型別資料的相關資訊，reference中儲存的直接就是物件地址，如果只是訪問物件本身的話，就不需要多一次間接訪問的開銷。
這兩種物件訪問方式各有優勢，使用控制代碼來訪問的最大好處就是reference中儲存的是穩定控制代碼地址，在物件被移動(垃圾收集時移動物件是非常普遍的行為)時只會改變控制代碼中的例項資料指標，而reference本身不需要被修改。
使用直接指標來訪問最大的好處就是速度更快，它節省了一次指標定位的時間開銷，由於物件訪問在Java中非常頻繁，因此這類開銷積少成多也是一項極為可觀的執行成本。
就虛擬機器HotSpot而言，它主要使用第二種方式進行物件訪問(有例外情況，如果使用了Shenandoah 收集器的話也會有一次額外的轉發)，但從整個軟體開發的範圍來看，在各種語言、框架中使用控制代碼來訪問的情況也十分常見。
3. 記憶體分配與回收
Java技術體系的自動記憶體管理，最根本的目標是自動化地解決兩個問題：自動給物件分配記憶體以及自動回收分配給物件的記憶體。對於回收記憶體這方面，即虛擬機器中的垃圾收集器體系以及運作原理。現在主要介紹給物件分配記憶體的那些事兒。
物件的記憶體分配，從概念上講，應該都是在堆上分配。在經典分代的設計下，新生物件通常會分配在新生代中，少數情況下(例如物件大小超過一定閾值)也可能會直接分配在老年代。物件分配的規則並不是固定的,這取決於虛擬機器當前使用的是哪一種垃圾收集器，以及虛擬機器中與記憶體相關的引數的設定。
3.1 物件優先在Eden分配
大多數情況下，物件在新生代Eden區中分配。當Eden區沒有足夠空間進行分配時，虛擬機器將發起一次 Minor GC。
HotSpot虛擬機器提供了-XX:+PrintGCDetails這個收集器日誌引數，告訴虛擬機器在發生垃圾收集行為時列印記憶體回收日誌、並且在程序退出的時候輸出當前的記憶體各區域分配情況。
3.2 大物件直接進入老年代
大物件就是指需要大量連續記憶體空間的Java物件，最典型的大物件便是那種很長的字串，或者元素數量很龐大的陣列。大物件對虛擬機器的記憶體分配來說就是一個不折不扣的壞訊息，比遇到一個大物件更加壞的訊息就是遇到一群“朝生夕滅”的“短命大物件”，我們寫程式的時候應注意避免。
在Java 虛擬機器中要避免大物件的原因是，在分配空間時，它容易導致記憶體明明還有不少空間時就提前觸發垃圾收集，以獲取足夠的連續空間才能安置好它們，而當複製物件時，大物件就意味著高額的記憶體複製開銷。HotSpot虛擬機器提供了-XX:PretenureSizeThreshold引數，指定大於該設定值的物件直接在老年代分配，這樣做的目的就是避免在Eden區及兩個Survivor區之間來回複製，產生大量的記憶體複製操作。
3.3 長期存活的物件進行老年代
HotSpot虛擬機器中多數收集器都採用了分代收集來管理堆記憶體，那記憶體回收時就必須能決策哪些存活物件應當放在新生代，哪些存活物件放在老年代中。為做到這點，虛擬機器給每個物件定義了一個物件年齡(Age)計數器，儲存在物件頭中。物件通常在Eden 區裡誕生，如果經過第一次Minor GC後仍然存活，並且能被Survivor 容納的話，該物件會被移動到Survivor空間中，並且將其物件年齡設為1歲。物件在Survivor區中每熬過次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度(預設為15)，就會被晉升到老年代中。物件晉升老年代的年齡閾值，可以透過引數-XX:MaxTenuringThreshold設定。
3.4 動態物件年齡判斷
為了能更好地適應不同程式的記憶體狀況，HotSpot虛擬機器並不是永遠要求物件的年齡須達到 -XX:MaxTenuringThreshold才能晉升老年代，如果在Survivor 空間中相同年齡所有物件大小的總和大於 Survivor 空間的一半，年齡大於或等於該年齡的物件就可以直接進老年代，無須等到-XX:MaxTenuringThreshold 中要求的年齡。
3.5 空間分配擔保
在發生MinorGC之前，虛擬機器必須先檢查老年代最大可用的連續空間是否大於新生代所有物件總空間，如果這個條件成立，那這一次Minor GC可以確保是安全的。如果不成立，則虛擬機器會先檢視-XX:HandlePromotionFaiure引數的設定值是否允許擔保失敗；如果允許，那會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代物件的平均大小，如果大於，將嘗試進行一次Minor GC，儘管這次Minor GC是有風險的；如果小於，或者-XX:HandlePromotionFailure 設定不允許冒險，那這時就要改為進行一次 Full GC。
JDK6Update 24之後的規則變為只要老年代的連續空間大於新生代物件總大小或者歷次晉升的平均大小，就會進行 Minor GC，否則將進行 Full GC。