深入理解Java虛擬機器之類執行時棧幀結構
棧幀（Stack Frame）是用於支援虛擬機器進行方法呼叫和方法執行的資料結構，它是虛擬機器執行時資料區中的虛擬機器棧（Virtual Machine Stack）的棧元素。棧幀儲存了方法的區域性變量表、運算元棧、動態連線和方法返回地址等資訊。每一個方法從呼叫開始至執行完成的過程，都對應著一個棧幀在虛擬機器棧裡面從入棧到出棧的過程。每一個棧幀都包括了局部變量表、運算元棧、動態連線、方法返回地址和一些額外的附加資訊。在編譯程式程式碼的時候，棧幀中需要多大的區域性變量表，多深的運算元棧都已經完全確定了，並且寫入到方法表的Code屬性之中，因此一個棧幀需要分配多少記憶體，不會受到程式執行期變數資料的影響，而僅僅取決於具體的虛擬機器實現。
一個執行緒中的方法呼叫鏈可能會很長，很多方法都同時處於執行狀態。對於執行引擎來說，在活動執行緒中，只有位於棧頂的棧幀才是有效的，稱為當前棧幀（Current Stack Frame），與這個棧幀相關聯的方法稱為當前方法（Current Method）。執行引擎執行的所有位元組碼指令都只針對當前棧幀進行操作，在概念模型上，典型的棧幀結構如圖所示。
image.png
區域性變量表
區域性變量表（Local Variable Table）是一組變數值儲存空間，用於存放方法引數和方法內部定義的區域性變數。在Java程式編譯為Class檔案時，就在方法的Code屬性的max_locals資料項中確定了該方法所需要分配的區域性變量表的最大容量。
區域性變量表的容量以變數槽（Variable Slot，下稱Slot）為最小單位，虛擬機器規範中並沒有明確指明一個Slot應占用的記憶體空間大小，只是很有導向性地說到每個Slot都應該能存放一個boolean、byte、char、short、int、float、reference或returnAddress型別的資料，這8種資料型別，都可以使用32位或更小的實體記憶體來存放，但這種描述與明確指出“每個Slot佔用32位長度的記憶體空間”是有一些差別的，它允許Slot的長度可以隨著處理器、作業系統或虛擬機器的不同而發生變化。只要保證即使在64位虛擬機器中使用了64位的實體記憶體空間去實現一個Slot，虛擬機器仍要使用對齊和補白的手段讓Slot在外觀上看起來與32位虛擬機器中的一致。
一個Slot可以存放一個32位以內的資料型別，Java中佔用32位以內的資料型別有boolean、byte、char、short、int、float、reference(Java虛擬機器規範中沒有明確規定reference型別的長度，它的長度與實際使用32還是64位虛擬機器有關，如果是64位虛擬機器，還與是否開啟某些物件指標壓縮的優化有關)和returnAddress 8種類型。第7種reference型別表示對一個物件例項的引用，虛擬機器規範既沒有說明它的長度，也沒有明確指出這種引用應有怎樣的結構。但一般來說，虛擬機器實現至少都應當能通過這個引用做到兩點，一是從此引用中直接或間接地查詢到物件在Java堆中的資料存放的起始地址索引，二是此引用中直接或間接地查詢到物件所屬資料型別在方法區中的儲存的型別資訊，否則無法實現Java語言規範中定義的語法約束。並不是所有語言的物件引用都能滿足這兩點，例如C++語言，預設情況下（不開啟RTTI支援的情況），就只能滿足第一點，而不滿足第二點。這也是為何C++中提供Java語言裡很常見的反射的根本原因。第8種即returnAddress型別目前已經很少見了，它是為位元組碼指令jsr、jsr_w和ret服務的，指向了一條位元組碼指令的地址，很古老的Java虛擬機器曾經使用這幾條指令來實現異常處理，現在已經由異常表代替。
對於64位的資料型別，虛擬機器會以高位對齊的方式為其分配兩個連續的Slot空間。Java語言中明確的（reference型別則可能是32位也可能是64位）64位的資料型別只有long和double兩種。值得一提的是，這裡把long和double資料型別分割儲存的做法與“long和double的非原子性協定”中把一次long和double資料型別讀寫分割為兩次32位讀寫的做法有些類似。不過，由於區域性變量表建立線上程的堆疊上，是執行緒私有的資料，無論讀寫兩個連續的Slot是否為原子操作，都不會引起資料安全問題。
虛擬機器通過索引定位的方式使用區域性變量表，索引值的範圍是從0開始至區域性變量表最大的Slot數量。如果訪問的是32位資料型別的變數，索引n就代表了使用第n個Slot，如果是64位資料型別的變數，則說明會同時使用n和n+1兩個Slot。對於兩個相鄰的共同存放一個64位資料的兩個Slot，不允許採用任何方式單獨訪問其中的某一個，Java虛擬機器規範中明確要求瞭如果遇到進行這種操作的位元組碼序列，虛擬機器應該在類載入的校驗階段丟擲異常。
在方法執行時，虛擬機器是使用區域性變量表完成引數值到引數變數列表的傳遞過程的，如果執行的是例項方法（非static的方法），那區域性變量表中第0位索引的Slot預設是用於傳遞方法所屬物件例項的引用，在方法中可以通過關鍵字“this”來訪問到這個隱含的引數。其餘引數則按照引數表順序排列，佔用從1開始的區域性變數Slot，引數表分配完畢後，再根據方法體內部定義的變數順序和作用域分配其餘的Slot。
為了儘可能節省棧幀空間，區域性變量表中的Slot是可以重用的，方法體中定義的變數，其作用域並不一定會覆蓋整個方法體，如果當前位元組碼PC計數器的值已經超出了某個變數的作用域，那這個變數對應的Slot就可以交給其他變數使用。不過，這樣的設計除了節省棧幀空間以外，還會伴隨一些額外的副作用，例如，在某些情況下，Slot的複用會直接影響到系統的垃圾收集行為
public static void main（String[]args）（）{
{
byte[] placeholder=new byte[64*1024*1024]；
}
int a=0；
System.gc（）；
}
執行一下程式，卻發現這次記憶體真的被正確回收了。
[GC 66401K-＞65778K（125632K），0.0035471 secs]
[Full GC 65778K-＞218K（125632K），0.0140596 secs]
placeholder能否被回收的根本原因是：區域性變量表中的Slot是否還存有關於placeholder陣列物件的引用。程式碼雖然已經離開了placeholder的作用域，但在此之後，沒有任何對區域性變量表的讀寫操作(即沒有int a=0這段程式碼)，placeholder原本所佔用的Slot還沒有被其他變數所複用，所以作為GC Roots一部分的區域性變量表仍然保持著對它的關聯。這種關聯沒有被及時打斷，在絕大部分情況下影響都很輕微。但如果遇到一個方法，其後面的程式碼有一些耗時很長的操作，而前面又定義了佔用了大量記憶體、實際上已經不會再使用的變數，手動將其設定為null值（用來代替那句int a=0，把變數對應的區域性變量表Slot清空）便不見得是一個絕對無意義的操作，這種操作可以作為一種在極特殊情形（物件佔用記憶體大、此方法的棧幀長時間不能被回收、方法呼叫次數達不到JIT的編譯條件）下的“奇技”來使用。
關於區域性變量表，還有一點可能會對實際開發產生影響，就是區域性變數不像前面介紹的類變數那樣存在“準備階段”。我們已經知道類變數有兩次賦初始值的過程，一次在準備階段，賦予系統初始值；另外一次在初始化階段，賦予程式設計師定義的初始值。因此，即使在初始化階段程式設計師沒有為類變數賦值也沒有關係，類變數仍然具有一個確定的初始值。但區域性變數就不一樣，如果一個區域性變數定義了但沒有賦初始值是不能使用的，不要認為Java中任何情況下都存在諸如整型變數預設為0，布林型變數預設為false等這樣的預設值。這段程式碼其實並不能執行，還好編譯器能在編譯期間就檢查到並提示這一點，即便編譯能通過或者手動生成位元組碼的方式製造出下面程式碼的效果，位元組碼校驗的時候也會被虛擬機發現而導致類載入失敗。
public static void main（String[]args）{
int a；
System.out.println（a）；
}
運算元棧
運算元棧（Operand Stack）也常稱為操作棧，它是一個後入先出（Last In First Out,LIFO）棧。同區域性變量表一樣，運算元棧的最大深度也在編譯的時候寫入到Code屬性的max_stacks資料項中。運算元棧的每一個元素可以是任意的Java資料型別，包括long和double。32位資料型別所佔的棧容量為1，64位資料型別所佔的棧容量為2。在方法執行的任何時候，運算元棧的深度都不會超過在max_stacks資料項中設定的最大值。
當一個方法剛剛開始執行的時候，這個方法的運算元棧是空的，在方法的執行過程中，會有各種位元組碼指令往運算元棧中寫入和提取內容，也就是出棧/入棧操作。例如，在做算術運算的時候是通過運算元棧來進行的，又或者在呼叫其他方法的時候是通過運算元棧來進行引數傳遞的。舉個例子，整數加法的位元組碼指令iadd在執行的時候運算元棧中最接近棧頂的兩個元素已經存入了兩個int型的數值，當執行這個指令時，會將這兩個int值出棧並相加，然後將相加的結果入棧。
運算元棧中元素的資料型別必須與位元組碼指令的序列嚴格匹配，在編譯程式程式碼的時候，編譯器要嚴格保證這一點，在類校驗階段的資料流分析中還要再次驗證這一點。再以上面的iadd指令為例，這個指令用於整型數加法，它在執行時，最接近棧頂的兩個元素的資料型別必須為int型，不能出現一個long和一個float使用iadd命令相加的情況。另外，在概念模型中，兩個棧幀作為虛擬機器棧的元素，是完全相互獨立的。但在大多虛擬機器的實現裡都會做一些優化處理，令兩個棧幀出現一部分重疊。讓下面棧幀的部分運算元棧與上面棧幀的部分區域性變量表重疊在一起，這樣在進行方法呼叫時就可以共用一部分資料，無須進行額外的引數複製傳遞，Java虛擬機器的解釋執行引擎稱為“基於棧的執行引擎”，其中所指的“棧”就是運算元棧。
image.png
動態連線
每個棧幀都包含一個指向執行時常量池中該棧幀所屬方法的引用，持有這個引用是為了支援方法呼叫過程中的動態連線（Dynamic Linking）。我們知道Class檔案的常量池中存有大量的符號引用，位元組碼中的方法呼叫指令就以常量池中指向方法的符號引用作為引數。這些符號引用一部分會在類載入階段或者第一次使用的時候就轉化為直接引用，這種轉化稱為靜態解析。另外一部分將在每一次執行期間轉化為直接引用，這部分稱為動態連線。（靜態分派，動態分派）
方法返回地址
當一個方法開始執行後，只有兩種方式可以退出這個方法。第一種方式是執行引擎遇到任意一個方法返回的位元組碼指令，這時候可能會有返回值傳遞給上層的方法呼叫者（呼叫當前方法的方法稱為呼叫者），是否有返回值和返回值的型別將根據遇到何種方法返回指令來決定，這種退出方法的方式稱為正常完成出口（Normal Method Invocation Completion）。
另外一種退出方式是，在方法執行過程中遇到了異常，並且這個異常沒有在方法體內得到處理，無論是Java虛擬機器內部產生的異常，還是程式碼中使用athrow位元組碼指令產生的異常，只要在本方法的異常表中沒有搜尋到匹配的異常處理器，就會導致方法退出，這種退出方法的方式稱為異常完成出口（Abrupt Method Invocation Completion）。一個方法使用異常完成出口的方式退出，是不會給它的上層呼叫者產生任何返回值的。
無論採用何種退出方式，在方法退出之後，都需要返回到方法被呼叫的位置，程式才能繼續執行，方法返回時可能需要在棧幀中儲存一些資訊，用來幫助恢復它的上層方法的執行狀態。一般來說，方法正常退出時，呼叫者的PC計數器的值可以作為返回地址，棧幀中很可能會儲存這個計數器值。而方法異常退出時，返回地址是要通過異常處理器表來確定的，棧幀中一般不會儲存這部分資訊。
方法退出的過程實際上就等同於把當前棧幀出棧，因此退出時可能執行的操作有：恢復上層方法的區域性變量表和運算元棧，把返回值（如果有的話）壓入呼叫者棧幀的運算元棧中，調整PC計數器的值以指向方法呼叫指令後面的一條指令等。