棧幀（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計數器的值以指向方法調用指令後面的一條指令等。
轉：