1.Class類文件結構
Class 文件是一組以 8 位字節為基礎單位的二進制流，各個數據項目嚴格按照順序緊湊地排列在 Class 文件之中，中間沒有添加任何分隔符，這使得整個 Class 文件中存儲的內容幾乎全部是程序運行的必要數據，沒有空隙存在。
當遇到需要占用 8 位字節以上空間的數據項時，則會按照高位在前（Big-Endian）的方式分割成若干個 8 位字節進行存儲。
根據 Java 虛擬機規范的規定，Class 文件格式采用一種類似於 C 語言結構體的偽結構來存儲數據，這種偽結構中只有兩種數據類型：無符號數和表，后面的解析都要以這兩種數據類型為基礎，所以這里要先介紹這兩個概念。
無符號數屬於基本的數據類型，以 u1、u2、u4、u8 來分別代表 1 個字節、2 個字節、4 個字節和 8 個字節的無符號數，無符號數可以用來描述數字、索引引用、數量值或者按照 UTF-8 編碼構成字符串值。
表是由多個無符號數或者其他表作為數據項構成的復合數據類型，所有表都習慣性地以 “_info” 結尾。表用於描述有層次關系的復合結構的數據，整個 Class 文件本質上就是一張表，它由表 6-1 所示的數據項構成。
表6-1
無論是無符號數還是表，當需要描述同一類型但數量不定的多個數據時，經常會使用一個前置的容量計數器，加若干個連續的數據項的形式，這時稱這一系列的某一類型的數據為某一類型的集合。
Class的結構不像XML等描述語言，由於它沒有任何分隔符號，所以在表6-1的數據項，無論是順序還是數量，甚至於數據存儲的字節序(Byte Ordering，Class 文件中字節序為 Big-Endian）這樣的細節，
都是被嚴格限定的，哪個字節代表什么含義，長度是多少，先后順序如何，都不允許改變。
2.魔數與Class文件的版本
每個Class文件的頭4個字節稱為魔數，它的唯一作用是確定這個文件是否為一個能被虛擬機接受的Class文件。很多文件儲存標准中都使用魔數來進行身份識別，譬如圖片格式，如 gif 或者 jpeg 等在文件頭中都存有魔數。
使用魔數而不是擴展名來僅從識別主要是基於安全方面的考慮，因為文件擴展名可以隨意地改動。文件格式的制定者額可以自由地選擇魔數值，只要這個魔數值還沒有被廣泛采用過同時又不會引起混淆即可。
Class 文件的魔數的獲得很有“浪漫氣息”，值為：0xCAFEBABE（咖啡寶貝？），這個魔數值再 Java 還稱做“Oak”語言的時候（大約是 1991 年前后）就已經確定下來了。
緊接着魔數的4個字節儲存的是Class文件的版本號：第5和第6個字節是次版本號，第7和第8個字節是主版本號。Java版本號是從45開始的，JDK1.1之后的每個JDK大版本發布主版本號向上加1（JDK 1.0 ~ 1.1 使用了 45.0 ~ 45.3 的版本號），
高版本的 JDK 能向下兼容以前版本的 Class 文件，但不能運行以后版本的 Class 文件，即使文件格式並未發生任何變化，虛擬機也必須拒絕執行超過其版本號的 Class 文件。
例如，JDK 1.1 能支持版本號為 45.0 ~ 45.65535 的 Class 文件，無法執行版本號為 46.0 以上的 Class 文件，而 JDK 1.2 則能支持 45.0 ~ 46.65535 的 Class 文件。 JDK 版本為 1.7，可生成的 Class 文件主版本號最大值為 51.0.
后面的內容都將以這段小程序使用 JDK 1.6 編譯輸出的 Class 文件為基礎來進行講解。如下：
package org.fenixsoft.clazz; public class TestClass { private int m; public int inc() { return m + 1; } }
下圖顯示的是使用十六進制編輯器WinHex打開這個Class文件的結果，可以清除的看見開頭4個字節的十六進制表示是0xCAFEBABE，代表此版本號的第5和第6個字節值為0x0000，而主版本號的值為0x0032,也即十進制的50，
改版本號說明這個文件是可以被JDK1.6或以上版本虛擬機執行的Class文件。
表 6-2 列出了從 JDK 1.1 到 JDK 1.7，主流 JDK 版本編譯器輸出的默認和可支持的 Class 文件版本號。
3.常量池
緊接着主次版本號之后的是常量池入口，常量池可以理解為Class文件之中的資源倉庫，它是Class文件結構中與其他項目關聯最多的數據類型，也是占用Class文件空間最大的數據項目之一，
同時它還是在Class文件中第一個出現的表類型數據項目。
由於常量池中常量的數量是不固定的，所以在常量池的入口需要設置一項u2類型的數據，代表常量池容量計數值。與Java中語言習慣不一樣的是，這個容量技術是從1而不是0開始的，如下圖表示，常量池容量（偏移地址：0x00000008）
為十六進制數0x0016，即十進制22，這代表常量池中有21項常量，索引值范圍為1~21。在Class文件格式規范制定之時，設計者將第0項常量空出來是有特殊考慮的，這樣做的目的在於滿足后面某些指向常量池的索引值的數據在特定情況下需要表達
"不引用任何一個常量池項目"的含義，這種情況就可以把索引值置為0來表示。Class文件結構中只有常量池的容量計數從1開始，對於其他集合類型，包括接口索引結合，字段表集合，方法表集合等容量技術都與一般習慣相同，從0開始。
常量池主要存放兩大類常量：字面量和符號引用。字面量比較接近Java語言層面的常量概念，如文本字符串，聲明為final的常量值等。而符號引用則屬於編譯原理方面的概念，包括了下面三類常量：
1.類和接口的全限定名
2.字段的名稱和描述符
3.方法的名稱和描述符
Java代碼在進行Javac編譯的時候，並不像C和C++那樣有“連接”這一步驟，而是在虛擬機加載Class文件的時候進行動態連接。也就是說，在Class文件中不會保存各個方法，字段的最終內存布局信息，因此這些字段，方法的符號引用不經過運行期轉換的話無法得到真正的內存
入口地址，也就無法直接被虛擬機使用。當虛擬機運行時，需要從常量池獲得對應的符號引用，再在類創建時或運行時解析，翻譯到具體的內存地址中。
常量池中每一項都是一個表，在JDK1.7之前共有11中結構不相同的表結構數據，在 JDK 1.7 中為了更好地支持動態語言調用，又額外增加了3 種(CONSTANT_MethodHandle_info,CONSTANT_MethodType_info和CONSTANT_InvokeDynamic_info)
這14種表都有一個共同的特點，就是表開始的第一位是一個u1類型的標志位(tag,取值見6-3中標識列),代表當前這個常量屬於哪種常量類型。
之所以說常量池是最煩鎖的數據，是因為這14種常量類型各自有自己的結構。回頭看看圖 6-3 中常量池的第一項常量，它的標志位（偏移地址：0x0000000A）是 0x07，查表 6-3 的標識列發現這個常量屬於 CONSTANT_Class_info 類型，
此類型的常量代表一個類或者接口的符號引用。CONSTANT_Class_info 的結構比較簡單，見表 6-4。
tag是標志位，上面已經講過了，它用於區分常量類型；name_index是一個索引值，它指向常量池中一個CONSTANT_Utf8_info類型常量，此常量代表了這個類(或者接口)的全限定名。這里name_index值（偏移地址：0x0000000B）為 0x0002，
也即是指向了常量池中的第二項常量。繼續從圖 6-3 中查找第二項常量，它的標志位（地址：0x0000000D）是 0x01，查表 6-3 可知確實是一個 CONSTANT_Utf8_info 類型的常量。CONSTANT_Utf8_info 類型的結構見表 6-5。
length值說明了這個UTF-8編碼的字符串長度傻逼多少字節，他后面緊跟着的長度為length字節的連續數據是一個使用UTF-8縮略編碼表示的字符串。UTF-8縮略編碼與普通UTF-8編碼的區別是：
從 '\u0800' 到 '\u07ff' 之間的所有字符的縮略編碼用兩個字節表示，從 '\u0800' 到 '\uffff' 之間的所有字符的縮略編碼接按照普通 UTF-8 編碼規則使用三個字節表示。
順便提一下，由於Class文件中方法，字段等都需要引用CONSTAN_Utf8_info型常量來描述名稱，所以CONSTAN_Utf8_info類型常量的最大長度也就是Java方法，字段名的最大長度。而這里的最大長度就是length的最大值，既u2類型能表達的最大值65535.
所以Java程序中如果定義了超過64KB英文字符的變量和方法名，將會無法編譯。
本例中這個字符串的length值（偏移地址：0x0000000E）為 0x001D，也就是長 29 字節，往后 29 字節正好都在 1 ~ 127 的 ASCII 碼范圍以內，內容為 “org/fenixsoft/clazz/TestClass”。一個個字節換算一下，換算結果如下：
到此為止，我們分析了 TestClass.class 常量池中 21 個常量中的兩個，其余的 19 個常量都可以通過類似的方法計算出來。為了避免計算過程占用過多的版面，后續的 19 個常量的計算過程可以借助計算機來幫我們完成。
在 JDK 的 bin 目錄中，Oracle 公司已經為我們准備好一個專門用於分析 Class 文件字節碼的工具：javap，代碼清單 6-2 中列出了使用 javap 工具 -verbose 參數輸出的 TestClass.class 文件字節碼內容（此清單中省略了常量池以為的信息）。
前面我們曾經提到過，Class 文件中還有很多數據項都要引用常量池中的常量，所以代碼清單 6-2 中的內容在后續的講解過程中還要經常使用到。
從代碼清單6-2中可以看出，計算機已經幫我們把整個常量池的21項常量都計算了出來，並且第1，2項常量的計算結果與我們手工計算的結果一致，仔細一看會發現，其中有一些常量似乎從你過來沒有在代碼中出現過，
如“I”、“V”、“<init>”、“LineNumberTable”、“LocalVariableTable”等，這些看起來在代碼任何一處都沒有出現過的常量是哪里來的呢？
這部分自動生成的常量的確沒有在Java代碼里面直接出現過，但它們會被后面即將講到的字段表（field_info）、方法表（method_info）、屬性表（attribute_info）引用到，它們會用來描述一些不方便使用“固定字節”進行
表達的內容。譬如描述方法的返回值是什么？有幾個參數？每個參數的類型是什么？因為Java中的類是無窮無盡的，無法通過簡單的無符號字節來描述一個方法用到了什么類，因此，在描述方法的這些信息時，需要引用常量表中的
符號引用進行表達。這部分內容將在后面進行一步闡述。這 14 種常量項的結構定義總結為表 6-6 以供讀者參考。
4.訪問標志
在常量池結束之后，緊接着的兩個字節代表訪問標志（access_flags），這個標志用於識別一些類或接口層次的訪問信息，包括：這個Class是類還是接口；是否定義為public類型；是否定義為abstrack類型；如果是類的話，
是否被聲明為final等。具體的標志位以及標志的含義見表 6-7。
access_flags 中一共有 16 個標志位可以使用，當前只定義了其中 8 個（注：在 Java 虛擬機規范中，只定義了開頭 5 種標志。JDK 1.5 中增加了后面三種。這些標志位在 JSR-202 規范中聲明。），
沒有使用到的標志位要求一律為 0。以代碼清單 6-1 中的代碼為例，TestClass 是一個普通 Java 類，不是借口、枚舉或者注解，被 public 關鍵字修飾但沒有被聲明 final 和 abstract，並且它使用了 JDK 1.2 之后的編譯器進行編譯，
因此它的 ACC_PUBLIC、ACC_SUPER 標志應當為真，而 ACC_FINAL、ACC_INTERFACE、ACC_ABSTRACT、ACC_SYNTHETIC、ACC_ANNOTATION、ACC_ENUM 這 6 個標志應當為假，
因此它的 access_flags 值應為：0x0001 | 0x0020 = 0x0021。從圖 6-5 中可以看出，access_flags 標志（偏移地址：0x000000EF）的確為 0x0021。
5.類索引，父索引與接口索引集合
類索引（this_class）和父類索引（super_class）都是一個u2 類型的數據，而接口索引集合（interfaces）是一組 u2 類型的數據的集合，Class文件中由這三項數據來確定這個類的繼承關系。類索引用於確定這個類的全限定名，
父類索引用於確定這個類的弗雷的全限定名。由於Java語言不允許多重繼承，所以父類索引只有一個，除了java.lang.Object 外，所有 Java 類的父類索引都不為 0。接口索引集合就用來描述這個類實現了哪些接口，這些被實現的接口就按implements語句
（如果這個類本身是一個接口，則應當是 extends 語句）后的接口順序從左到右排列在接口索引集合中。
類索引，父類索引和接口索引集合都按照順序排列在訪問標志之后，類索引和父類索引用兩個u2類型的索引值表示，它們各自指向一個類型為CONSTANT_Class_info的類描述符常量，通過CONSTANT_Class_info類型的常量中的索引值可以
找到定義在CONSTAN_Utif8_info類型的常量中的全限定名字符串。圖6-6表演了上面代碼的類索引查找過程。
對於接口索引集合，入口的第一項——u2類型的數據為接口計數器表示索引表的容量。如果該類沒有實現任何接口，則該技術值為0，后面接口的索引表不再占用任何字節。代碼清單6-1中的代碼的類索引，父類索引與接口表索引的內容如圖6-7所以
從偏移量地址0x000000F1 開始的 3 個 u2 類型的值分別為 0x0001、0x0003、0x0000，也就是類索引為 1，父類索引為 3，接口索引集合大小為 0，查詢前面代碼清單 6-2 中 javap 命令計算出來的常量池，找出對應的類和父類的常量，結果如代碼清單 6-3 所示。
6.字段表集合
字段表（field_info）用於描述接口或者類中聲明的變量。字段（field）包括類級變量以及實例變量，但不包括在方法內部聲明的局部變量。我們可以想一想在 Java 中描述一個字段可以包含什么信息？
可以包括的信息有：字段的作用域（public、private、protected 修飾符）、是實例變量還是類變量（static 修飾符）、可變性（final）、並發可見性（volatile 修飾符，是否強制從主內存讀寫）、可否被序列化（transient 修飾符）、字段數據類型（基本類型、對象、數組）、字段名稱。
上述這些信息中，各個修飾符都是布爾值，要么有某個修飾符，要么沒有，很適合使用標志位來表示。而字段叫什么名字、字段被定義為什么數據類型，這些都是無法固定的，只能引用常量池中的常量來描述。表 6-8 中列出了字段表的最終格式。
字段修飾符放在access_flags 項目中，它與類中的 access_flags 項目是非常類似的，都是一個 u2 的數據類型，其中可以設置的標志位和含義見表 6-9。
很明顯，在實際情況中，ACC_PUBLIC、ACC_PRIVATE、ACC_PROTECTED 三個標志最多只能選擇其一，ACC_FINAL、ACC_VOLATILE 不能同時選擇。接口之中的字段必須有 ACC_PUBLIC、ACC_STATIC、ACC_FINAL 標志，這些都是由 Java 本身的語言規則所決定的。
跟隨access_flags標志的是兩項索引值：name_index和descriptor_index。它們都是對常量池的引用，分別代表着字段的簡單名稱以及字段和方法的描述符。現在需要解釋一下“簡單名稱”、“描述符”以及前面出現過多次的“全限定名”這三種特殊字符串的概念。
全限定名和簡單名稱很好理解，以代碼清單6-1中的代碼為例，“org/fenixsoft/clazz/TestClass”是這個類的全限定名，僅僅是把類全名中的“.”替換成了“/”而已，為了使連續的多個全限定名之間不產生混淆，在使用時最后一般會加入一個";"表示全限定名結束。
簡單名稱是指沒有類型和參數修飾的方法或者字段名稱，這個類中的inc()方法和m字段的簡單名稱分別是inc和m
相對於全限定名和簡單名稱來說，方法和字段的描述符就要復雜一些。描述符的作用是用來描述字段的數據類型，方法的參數列表(包括數量，類型以及順序)和返回值。
根據描述符規則，基本數據類型（byte、char、double、float、int、long、short、boolean）以及代表無返回值的 void 類型都用一個大寫字符來表示，而對象類型則用字符 L加對象的全限定名來表示，詳見表 6-10。
對於數組類型，每一維度將使用一個前置的“[”字符來描述，如一個定義為“java.lang.String[][]” 類型的二維數組，將被記錄為：“[[Ljava/lang/String;”，一個整型數組 “int[]” 將被記錄為 “[I”。
用描述符來描述方法時，按照先參數列表，后返回值的順序描述，參數列表按照參數的嚴格順序放在一組小括號“()”之內。如方法void inc()的描述符為“()V”,
方法 java.lang.String toString() 的描述符為 “()Ljava/lang/String;”，方法 int indexOf(char[] source, int sourceOffset, int sourceCount, char[]target, int targetOffset, int targetCount, int fromIndex)的描述符為 “([CII[CIII)I”。
對於代碼清單 6-1 中的 TestClass.class 文件來說，字段表集合從地址 0x000000F8 開始，第一個 u2 類型的數據為容量計數器 fields_count，如圖 6-8 所示。其值為 0x0001，說明這個類只有一個字段表數據。
接下來緊跟着容量計數器的是 access_flags 標志，值為 0x0002，代表 private 修飾符的 ACC_PRIVATE 標志位為真（ACC_PRIVATE 標志的值為 0x0002），其他修飾符為假。代表字段名稱的 name_index 的值為 0x0005，
從代碼清單 6-2 列出的常量表中可查得第 5 項常量是一個 CONSTANT_Utf8_info 類型的字符串，其值為“m”，代表字段描述符的 descriptor_index 的值為 0x0006，指向常量池的字符串“I”，根據這些信息，我們可以推斷出原代碼定義的字段為：“private int m;”。
字段表都包含的固定數據項目到 descriptor_index 為止就結束了，不過在 descriptor_index 之后跟隨着一個屬性表集合用於存儲一些額外的信息，字段都可以在屬性表中描述零至多項的額外信息。
對於本例中的字段 m，它的屬性表計數器為 0，也就是沒有需要額外描述的信息，但是，如果將字段 m 的聲明改為 “final static int m=123;”，那就可能會存在一項名稱為 ConstantValue 的屬性，其值指向常量 123。
字段表集合中不會列出從超類或者父接口中繼承而來的字段，但有可能列出原本 Java 代碼之中不存在的字段，譬如在內部類中為了保持對外部類的訪問性，會自動添加指向外部類實例的字段。
另外，在 Java 語言中字段是無法被重載的，兩個字段的數據類型、修飾符不管是否相同，都必須使用不一樣的名稱，但是對於字節碼來將，如果兩個字段的描述符不一致，那字段重名就是合法的。
7.方法集合
如果理解了上面字段表的內容，那么方法表的內容將會變得很簡單。Class文件存儲格式中對方法的描述與對字段的描述幾乎采用了完全一致的方式，
方法表的結構如同字段表一樣依次包括了訪問標志（access_flags）、名稱索引（name_index）、描述符索引（descriptor_index）、屬性表集合（attributes）幾項，見表 6-11。這些數據項目的含義也非常類似，僅在訪問標志和屬性表集合的可選項中有所區別。
因為volatile關鍵字和transient關鍵字不能修飾方法，所以方法表的訪問標志中沒有了ACC_VOLATILE標志和ACC_TRANSIENT標志。與之相對的，synchronized、native、strictfp 和 abstract 關鍵字可以修飾方法，
所以方法表的訪問標志中增加了 ACC_SYNCHRONIZED、ACC_NATIVE、ACC_STRICTFP 和 ACC_ABSTRACT 標志。對於方法表，所有標志位及其取值可參見表 6-12。
行文至此，也許會產生疑問，方法的定義可以通過訪問標志、名稱索引、描述符索引表達清楚，但方法里面的代碼去哪里了？方法里的 Java 代碼，經過編譯器編譯成字節碼指令后，
存放在方法屬性表集合中一個名為 “Code” 的屬性里面，屬性表作為 Class 文件格式中最具擴展性的一種數據項目，將在下一節（屬性表集合）中詳細講解。
繼續以上面的代碼清單中的Class文件為例對方法集合進行分析，如6-9所示，方法集合的入口地址為0x00000101,第一個u2類型的數據(即是計數器容量)的值為0x0002，代表集合中有兩個方法(這兩個方法為編譯器添加的實例構造<init>和源碼中的方法inc()）。
第一個方法的訪問標志值為 0x0001，也就是只有 ACC_PUBLIC 標志為真，名稱索引值為 0x0007，查代碼清單 6-2 的常量池得方法名為“<init>”，描述符索引值為 0x0008，對應常量為“()V”，屬性表計數器 attributes_count 的值為 0x0001 就表示此方法的屬性表集合有一項屬性，屬性名稱索引為 0x0009，對應常量為“Code”，說明此屬性是方法的字節碼描述。
與字段表集合相對應的，如果父類方法在子類中沒有被重寫，方法集合中就不會出現來自父類的方法信息。但同樣的，有可能會出現由編譯器自動添加的方法，最經型的便是類構造器"<clinit>"方法和實例構造器“<init>”方法。
在 Java 語言中，要重載（Overload）一個方法，除了要與原方法具有相同的簡單名稱之外，還要求必須擁有一個與原方法不同的特征簽名（注：Java 代碼的方法特征簽名只包括方法名稱、參數順序及參數類型，而字節碼的特征簽名還包括方法返回值以及受查異常表），特征簽名就是一個方法中各個參數在常量池中的字段符號引用的集合，也就是因為返回值不會包含在特征簽名中，因此 Java 語言里面是無法僅僅依靠返回值的不同來對一個已有方法進行重載的。但是在 Class 文件格式中，特征簽名的范圍更大一些，只要描述符不是完全一致的兩個方法也可以共存。也就是說，如果兩個方法有相同的名稱和特征簽名，但返回值不同，那么也是可以合法共存於同一個 Class 文件中的。
8.屬性表集合
屬性表（attribute_info）在前面的講解之中已經出現過數次，在 Class 文件、字段表、方法表都可以攜帶子機的屬性表集合，以用於描述某些場景專有的信息。
與 Class 文件中其他的數據項目要求嚴格的順序、長度和內容不同，屬性表集合的限制稍微寬松了一些，不再要求各個屬性表具有嚴格順序，並且只要不與已有屬性名重復，任何人實現的編譯器都可以向屬性表中寫入自己定義的屬性信息，
Java 虛擬機運行時會忽略掉它不認識的屬性。為了能正確解析 Class 文件，《Java 虛擬機規范（第 2 版）》中預定義了 9 項虛擬機實現應當能識別的屬性，而在最新的《Java 虛擬機規范（Java SE 7）》版中，
預定義屬性已經增加到 21 項，具體內容見表 6-13。下文中將對其中一些屬性中的關鍵常用的部分進行講解。
6-13
對於每個屬性，它的名稱需要從常量池中引用一個 CONSTANT_Utf8_info 類型的常量來表示，而屬性值的結構則是完全自定義的，只需要通過一個 u4 的長度屬性去說明屬性值所占用的位數即可。一個符合規則的屬性表應該滿足表 6-14 中所定義的結構。
9.Code屬性
Java程序方法體中的代碼經過Javac編譯器處理后，最終變為字節碼指令存儲在Code屬性內。Code屬性出現在方法表的屬性集合中，但並非所有的方法都不許存在這個屬性，譬如接口或者抽象類中的方法就不存在Code屬性，如果
方法表有Code屬性存在，那么它的結構如表6-15所示。
attribute_name_index 是一項指向 CONSTANT_Utf8_info 型常量的索引，常量值固定為“Code”，它代表了該屬性的屬性名稱，attribute_length 指示了屬性值的長度，由於屬性名稱索引與屬性長度一共為 6 字節，所以屬性值的長度固定為整個屬性表長度減去 6 個字節。
max_stack 代表了操作數棧（Operand Stacks）深度的最大值。在方法執行的任意時刻，操作數棧都不會超過這個深度。虛擬機運行的時候需要根據這個值來分配棧幀（Stack Frame）中的操作棧深度。
max_locals 代表了局部變量表所需的存儲空間，在這里，max_locals 的單位是 Slot，Slot 是虛擬機為局部變量分配內存所使用的最小單位。對於 byte、char、float、int、short、boolean 和 returnAddress 等長度不超過 32 位的數據類型，每個局部變量占用 1 個 Slot，
而 double 和 long 這兩種 64 位的數據類型則需要兩個 Slot 來存放。方法參數（包括實例方法中的隱藏參數 “this”）、顯式異常處理器的參數（Exception Handler Parameter，就是 try-catch 語句中 catch 塊所定義的異常）、方法體中定義的局部變量都需要使用局部變量表來存放。
另外，並不是在方法中用到了多少個局部變量，就把這些局部變量所占 Slot 之和作為 max_locals 的值，原因是局部變量表中的 Slot 可以重寫，當代碼執行超出一個局部變量的作用域時，這個局部變量所占的 Slot 可以被其他局部變量所使用，
Javac 編譯器會根據變量的作用域來分配 Slot 給各個變量使用，然后計算出 max_locals 的大小。
code_length 和 code 用來存儲 Java 源程序編譯后生成的字節碼指令。code_length 代表字節碼長度，code 是用於存儲字節碼指令的一系列字節流。既然叫字節碼指令，那么每個指令就是一個 u1 類型的單字節，當虛擬機讀取到 code 中的一個字節碼時，
就可以對應找出這個字節碼代表的是什么指令，並且可以知道到這條指令后面是否需要跟隨參數，以及參數應當如何理解。我們知道一個 u1 數據類型的取值范圍為 0x00 ~ 0xFF，對應十進制的 0 ~ 255，也就是一共可以表達 256 條指令，目前，Java 虛擬機規范已經定義了其中約 200 條編碼值對應的指令含義。
關於 code_length，有一件值得注意的事情，雖然它是一個 u4 類型的長度值，理論上最大值可以達到 2^23-1，但是虛擬機規范中明確限制了一個方法不允許超過65535 條字節碼指令，即它實際只使用了 u2 的長度，如果超過這個限制，Javac 編譯器也會拒絕編譯。一般來講，編寫 Java 代碼時只要不是刻意去編寫一個超長的方法來為難編譯器，是不太可能超過這個最大值的限制。但是，某些特殊情況，例如在編譯一個很復雜的 JSP 文件時，某些 JSP 編譯會把 JSP 內容和頁面輸出的信息歸並於一個方法之中，就可能因為方法生成字節碼超長的原因而導致編譯失敗。
Code 屬性是 Class 文件中最重要的一個屬性，如果把一個 Java 程序中的信息分為代碼（Code，方法體里面的 Java 代碼）和元數據（Metadata，包括類、字段、方法定義及其他信息）量部分，那么在整個 Class 文件中，Code 屬性用於描述代碼，所有的其他數據項目都用於描述元數據。了解 Code 屬性是學習后面關於字節碼執行引擎內容的必要基礎，能直接閱讀字節碼也是工作中分析 Java 代碼語義問題的必要工具和基本技能，因此筆者准備了一個比較詳細的實例來講解虛擬機是如何使用這個屬性的。
繼續以代碼清單 6-1 的 TestClass.class 文件為例，如圖 6-10 所示，這是上一節分析過的實例構造器“<init>”方法的 Code 屬性。它的操作數棧的最大深度和本地變量表的容量都為 0x0001，字節碼區域所占空間的長度為 0x0005。虛擬機讀取到字節碼區域的長度后，按照順序依次讀入緊隨的 5 個字節，並根據字節碼指令表翻譯出所對應的字節碼指令。翻譯“2A B7 00 0A B1”的過程為：
- 讀入 2A，查表得 0x2A 對應的指令為 aload_0，這個指令的含義是將第 0 個 Slot 中為 reference 類型的本地變量推送到操作數棧頂。
- 讀入 B7，查表得 0xB7 對應的指令為 invokespecial，這條指令的作用是以棧頂的 reference 類型的數據所指向的對象作為方法接受者，調用此對象的實例構造器方法、private 方法或者它的父類的方法。這個方法有一個 u2 類型的參數說明具體調用哪一個方法，它指向常量池中的一個 CONSTANT_Methodref_info 類型常量，即此方法的方法符號引用。
- 讀入 00 0A，這是一 invokespecial 的參數，查常量池得 0x000A 對應的常量為實例構造器“<init>”方法的符號引用。
- 讀入 B1，查表得 0xB1 對應的指令為 return，含義是返回此方法，並且返回值為 void。這條指令執行后，當前方法結束。
這段字節碼雖然很短，但是至少可以看出它的執行過程中的數據交換、方法調用等操作都是基於棧（操作棧）的。我們可以初步猜測：Java 虛擬機執行字節碼是基於棧的體系結構。但是與一般基於堆棧的零字節指令又不太一樣，某些指令（如 invokespecial）后面還會帶有參數。
我們再次使用 javap 命令把此 Class 文件中的另外一個方法的字節碼指令也計算出來，結果如代碼清單 6-4 所示。
如果大家注意到 javap 中輸出的 “args_size”的值，可能會有疑問：這個類有兩個方法——實例構造器<init>() 和 inc()，這兩個方法很明顯都是沒有參數的，為什么 args_size 會為 1？而且無論是在參數列表里還是方法體內，都沒有定義任何局部變量，
那 Locals 又為什么會等於1？如果有這樣的疑問，大家可能是忽略了一點：在任何實例方法里面，都可以通過“this” 關鍵字訪問到此方法所屬的對象。這個方法機制對 Java 程序的編寫很重要，而它的實現卻非常簡單，
僅僅是通過 javac 編譯器編譯的時候把對 this 關鍵字的訪問轉變為對一個普通方法參數的訪問，然后在虛擬機調用實例方法時自動傳入此參數而已。因此在實例方法的局部變量表中至少會存在一個指向當前對象實例的局部變量，
局部變量表中也會預留出第一個 Slot 位來存放對象實例的引用，方法參數值從 1 開始計算。這個處理只對實例方法有效，如果代碼清單 6-1 中的 inc() 方法聲明為 static，那 args_size 就不會等於 1 而是等於 0 了。
在字節碼指令之后的是這個方法顯示異常處理表（下文簡稱異常表）集合，異常表對於 Code 屬性來說並不是必須存在的，如代碼清單 6-4 中就沒有異常表生成。
異常表的格式如表 6-16 所示，它包含 4 個字段，這些字段的含義為：如果當字節碼在第 start_pc 行（注：此處字節碼的 “行” 是一種形象的描述，指的是字節碼相對於方法體開始的偏移量，
而不是 Java 源碼的行號）到第 end_pc 行之間（不含第 end_pc 行）出現了類型為 catch_type 或者其子類的異常（catch_type 為指向一個 CONSTANT_Class_info 型常量的索引），則轉到第 handler_pc 行繼續處理。當catch_type的值為 0時，代表任意異常情況都需要轉向到 handler_pc 處進行處理。
異常表實際上是 Java 代碼的一部分，編譯器使用異常表而不是簡單的跳轉命令來實現Java 異常及 finally 處理機制。
代碼清單 6-5 是一段演示異常表如何運作的例子，這段代碼主要演示了在字節碼層面中 try-catch-finally 是如何實現的。在閱讀字節碼之前，大家不妨先看看下面的 Java 源碼，想一下這段代碼的返回值在出現異常和不出現異常的情況下分別應該是多少？
編譯器為這段 Java 源碼生成了 3 條異常表記錄，對應 3 條可能出現的代碼執行路徑。從 Java 代碼的語義上講，這 3 條執行路徑分別為：
- 如果 try 語句塊中出現屬於 Exception 或其子類的異常，則轉到 catch 語句塊處理。
- 如果 try 語句塊中出現不屬於 Exception 或器子類的異常，則轉到 finally 語句塊處理。
- 如果 catch 語句塊中出現任何異常，則轉到 finally 語句塊處理。
返回到我們上面提出的問題，這段代碼的返回值應該是多少？對 Java 語言熟悉的讀者應該很容易說出答案：如果沒有出現異常，返回值是 1；如果出現了 Exception 異常，返回值是 2；如果出現了 Exception 以外的異常，方法非正常退出，沒有返回值。我們一起來分析一下字節碼的執行過程，從字節碼的層面上看看為何會有這樣的返回結果。
字節碼中第 0 ~ 4 行所做的操作就是將整數 1 賦值非變量 x，並且將此時 x 的值復制一份副本到最后一個本地變量表的 Slot 中（這個 Slot 里面的值在 ireturn 指令執行前將會被重新讀到操作棧頂，作為方法返回值使用。為了講解方便，筆者給這個 Slot 起了個名字：returnValue）。如果這時沒有出現異常，則會繼續走到第 5~9 行，將變量 x 賦值為 3，然后將之前保存在 returnValue 中的整數 1 讀入到操作棧頂，最后 ireturn 指令會以 int 形式返回操作棧頂的 值，方法結束。如果出現了異常，PC 寄存器指針轉到第 10 行，第 10 ~ 20 行所做的事情是將 2 賦值給變量 x，然后將變量 x 此時的值賦給 returnValue，最后再將變量 x 的值改為 3。方法返回前同樣將 returnValue 中保留的整數 2 讀到了操作棧頂。從第 21 行開始的代碼，作用是變量 x 的值復位 3，並將棧頂的異常拋出，方法結束。
盡管大家都知道這段代碼出現異常的概率非常小，但並不影響我們演示異常表的作用。
10.Exception屬性
這里的 Exceptions 屬性是在方法表中與 Code 屬性平級的一項屬性，讀者不要與前面剛剛講解完的異常表產生混淆。Exceptions 屬性的作用是列舉出方法中可能拋出的受檢查異常（Checked Exceptions），也就是方法描述時在 throws 關鍵字后面列舉的異常。它的結構見表 6-17。
11.LineNumberTable屬性
LineNumberTable 屬性用於描述 Java 源碼行號與字節碼行號（字節碼的偏移量）之間的對應關系。它並不是運行時必需的屬性，但默認會生成到 Class 文件之中，可以在 javac 中分別使用 -g:none 或 -g:lines 選項來取消或要求生成這項信息。如果選擇不生成LineNumberTable 屬性，對程序運行產生的最主要的影響就是當拋出異常時，堆棧中將不會顯示出錯的行號，並且在調試程序的時候，也無法按照源碼行來設置斷點。LineNumberTable 屬性的結構見表 6-18。
line_number_table 是一個數量為 line_number_table_length、類型為 line_number_info 的集合，line_number_info 表包括了 start_pc 和 line_number 兩個 u2 類型的數據項，前者是字節碼行號，后者是 Java 源碼行號。
12.LocalVariableTable屬性
LocalVariableTable 屬性用於描述棧幀中局部變量表中的變量與 Java 源碼中定義的變量之間的關系，它也不是運行時必需的屬性，但默認會生成到 Class 文件之中，可以在 Javac 中分別使用 -g:none 或 -g:vars 選項來取消或要求生成這項信息。如果沒有生成這項屬性，最大的影響就是當其他人引用這個方法時，所有的參數名稱都將會丟失，IDE 將會使用諸如 arg0、arg1 之類的占位符代替原有的參數名，這對程序運行沒有影響，但是會對代碼編寫帶來較大不變，而且在調試期間無法根據參數名稱從上下文獲得參數值。LocalVariableTable 屬性的結構見表 6-19。
其中，local_variable_info 項目代表了一個棧幀與源碼中的局部變量的關聯，結構見表 6-20
start_pc 和 length 屬性分別代表了這個局部變量的生命周期開始的字節碼偏移量及其作用范圍覆蓋的長度，兩者結合起來就是這個局部變量在字節碼之中的作用域范圍。
name_index 和 descriptor_index 都是指向常量池中 CONSTANT_Utf8_info 型常量的索引，分別代表了局部變量的名稱以及這個局部變量的描述符。
index 是這個局部變量在棧幀局部變量表中 Slot 的位置。當這個變量數據類型是 64 位類型時（double 和 long），它占用的 Slot 為 index 和 index+1 兩個。
順便提一下，在 JDK 1.5 引入泛型之后，LocalVariableTable 屬性增加了一個 “姐妹屬性”：LocalVariableTypeTable，這個新增的屬性結構與 LocalVariableTable 非常相似，僅僅是把記錄的字段描述符的 descriptor_index 替換成了字段的特征簽名（Signature），
對於非泛型類型來說，描述符和特征簽名能描述的信息是基本一致的，但是泛型引入之后，由於描述符中泛型的參數化類型被擦除掉，描述符就不能准確地描述泛型類型了，因此出現了 LocalVariableTypeTable。
12.SourceFile屬性
SourceFile 屬性用於記錄生成這個 Class 文件的源碼文件名稱。這個屬性也是可選的，可以分別使用 javac 的 -g:none 或 -g:source 選項來關閉或要求生成這項信息。在 Java 中，對於大多數的類來說，類名和文件名是一致的，但是又一些特殊情況（如內部類）例外。如果不生成這項屬性，當拋出異常時，堆棧中將不會顯示出錯代碼所屬的文件名。這個屬性是一個定長的屬性，其結構見表 6-21。
sourcefile_index 數據項是指向常量池中 CONSTANT_Utf8_info 型常量的索引，常量值是源碼文件的文件名。
13.ConstantValue屬性
ConstantValue 屬性的作用是通知虛擬機自動為靜態變量賦值。只有被 static 關鍵字修飾的變量（類變量）才可以使用這項屬性。類似 “int x = 123” 和 “static int x = 123” 這樣的變量定義在 Java 程序中是非常常見的事情，但虛擬機對這兩種變量賦值的方式和時刻都有所不同。對於非 static 類型的變量（也就是實例變量）的賦值是在實例構造器 <init> 方法中進行的；而對於類變量，則有兩種方式可以選擇：在類構造器 <clinit> 方法中或者使用 ConstantValue 屬性。目前 Sun Javac 編譯器的選擇是：如果同時使用 final 和 static 來修飾一個變量（按照習慣，這里稱 “常量” 更貼切），並且這個變量的數據類型是基本類型或者 java.lang.String 的話，就生成 ConstantValue 屬性來進行初始化，如果這個變量沒有被 final 修飾，或者並非基本類型及字符串，則將會選擇在 <clinit> 方法中進行初始化。
雖然有 final 關鍵字 才更符合 “ConstantValue” 的語義，但虛擬機規范中並沒有強制要求字段必須設置了 ACC_FINAL 標志，只要求了有 ConstantValue 屬性的字段必須設置 ACC_STATIC 標志而已，對 final 關鍵字的要求是 javac 編譯器自己加入的限制。而對 ConstantValue 的屬性值只能限於基本類型和 String，不過筆者不認為這是什么限制，因為此屬性值只是一個常量池的索引號，由於 Class 文件格式的常量類型中只有與基本屬性和字符串相對應的字面量，所以就算 ConstantValue 屬性想支持別的類型也無能為力。ConstantValue 屬性的結構見表 6-22。
從數據結構中可以看出，ConstantValue 屬性是一個定長屬性，它的 attribute_length 數據項值必須固定為 2。constantvalue_index 數據項代表了常量池中一個字面量常量的引用，根據字段類型的不同，字面量可以是CONSTANT_Long_info、CONSTANT_Float_info、CONSTANT_Double_info、CONSTANT_Integer_info、CONSTANT_String_info常量中的一種。
14.InnerClass屬性
InnerClass 屬性用於記錄內部類與宿主類之間的關聯。如果一個類中定義了內部類，那編譯器將會為它以及它所包含的內部類生成 InnerClass 屬性。該屬性的結構見表 6-23。
數據項 number_of_classes 代表需要記錄多少個內部類信息，每一個內部類的信息都由一個 inner_classes_info 表進行描述。inner_classes_info 表的結構見表 6-24。
inner_class_info_index 和 outer_class_info_index 都是指向常量池中 CONSTANT_Class_info 型常量的索引，分別代表了內部類和宿主類的符號引用。
inner_name_inex 是指向常量池中 CONSTANT_Utf8_info 型常量的索引，代表這個內部類的名稱，如果是匿名內部類，那么這項值為 0。
inner_class_access_flags 是內部類的訪問標志，類似於類的 access_flags，它的取值范圍見表 6-25。
15.Deprecated及Synthetic屬性
Deprecated 和 Synthetic 兩個屬性都屬於標志類型的布爾屬性，只存在有和沒有的區別，沒有屬性值的概念。
Deprecated 屬性用於表示某個類、字段或者方法，已經被程序作者定為不再推薦使用，它可以通過在代碼中使用 @deprecated 注釋進行設置。
Synthetic 屬性代表此字段或者方法並不是由 Java 源碼直接產生的，而是由編譯器自行添加的，在 JDK 1.5 之后，標識一個類、字段或者方法是編譯器自動產生的，也可以設置它們訪問標志中的 ACC_SYNTHETIC 標志位，其中最典型的例子就是 Bridge Method。所有由非用戶代碼產生的類、方法及字段都應當至少設置 Synthetic 屬性和 ACC_SYNTHETIC 標志位中的一項，唯一的例外是實例構造器 “<init>” 方法和類構造器 “<clinit>” 方法。
Deprecated 和 Synthetic 屬性的結構非常簡單，見表 6-26。
其中attribute_length數據項的值必須為0x00000000，因為沒有任何屬性值需要設置
16.StackMapTable屬性
StackMapTable 屬性在 JDK 1.6 發布后增加到了 Class 文件規范中，它是一個復雜的變長屬性，位於 Code 屬性的屬性表中。這個屬性會在虛擬機類加載的字節碼驗證階段被新類型檢查驗證器（Type Checker）使用，目的在於代替以前比較消耗性能的基於數據流分析的類型推導驗證器。
這個類型檢查驗證器最初來源於 Sheng Liang（聽名字似乎是虛擬機團隊中的華裔成員）為 Java ME CLDC 實現的字節碼驗證器。新的驗證器在同樣能保證 Class 文件合法性的前提下，省略了在運行期通過數據流分析去確認字節碼的行為邏輯合法性的步驟，而是在編譯階段將一系列的驗證類型（Verification Types）直接記錄在 Class 文件之中，通過檢查這些驗證類型代替了類型推導過程，從而大幅提升了字節碼驗證的性能。這個驗證器在 JDK 1.6 中首次提供，並在 JDK 1.7 中強制代替原本基於類型推斷的字節碼驗證器。關於這個驗證器的工作原理，《Java 虛擬機規范（Java SE 7版）》花費了整整 120 頁的篇幅來講解描述，並且分析證明新驗證方法的嚴謹性。
StackMapTable 屬性中包含零至多個棧映射幀（Stack Map Frames），每個棧幀映射幀都顯示或隱式地代表了一個字節碼偏移量，用於表示該執行到該字節碼時局部變量表和操作數棧的驗證類型。類型檢查驗證器會通過檢查目標方法的局部變量和操作數棧所需要的類型來確定一段字節碼指令是否符合邏輯約束。StackMapTable 屬性的結構見表 6-27。
《Java 虛擬機規范（Java SE 7 版）》明確規定：在版本號大於或等於 50.0 的 Class 文件中，如果方法的 Code 屬性中沒有附帶 StackMapTable 屬性，那就意味着它帶有一個隱式的 StackMap 屬性。這個 StackMap 屬性的作用等同於 number_of_entries 值為 0 的 StackMapTable 屬性。一個方法的 Code 屬性最多只能有一個 StackMapTable 屬性，否則將拋出 ClassFormatError 異常。
17.Signature屬性
Signature 屬性在 JDK 1.5 發布后增加到了 Class 文件規范之中，它是一個可選的定長屬性，可以出現於類、屬性表和方法表結構的屬性表中。在 JDK 1.5 中大幅增強了 Java 語言的語法，在此之后，任何類、接口、初始化方法或成員的泛型簽名如果包含了類型變量（Type Variables）或參數化類型（Parameterized Types），則 Signature 屬性會為它記錄泛型簽名信息。之所以要專門使用這樣一個屬性去記錄泛型類型，是因為 Java 語言的泛型采用的是擦除法實現的偽泛型，在字節碼（Code 屬性）中，泛型信息編譯（類型變量、參數化類型）之后都通通被擦除掉。使用擦除法的好處是實現簡單（主要修改 Javac 編譯器，虛擬機內部只做了很少的改動）、非常容易實現 backport，運行期也能夠節省一些類型所占的內存空間。但壞處是運行期就無法像 C# 等有真泛型支持的語言那樣，將泛型類型與用戶定義的普通類型同等對待，例如運行期做反射時無法獲得泛型信息。Signature 屬性就是為了彌補這個缺陷而增設的，現在 Java 的反射 API 能夠獲取泛型類型，最終的數據來源也就是這個屬性。Signature 屬性的結構見表 6-28。
其中 signature_index 項的值必須是一個對常量池的有效索引。常量池在該索引處的項必須是 CONSTANT_Utf8_info 結構，表示類簽名、方法類型簽名或字段類型簽名。如果當前 Signature 屬性是類文件的屬性，則這個結構表示類簽名，如果當前的 Signature 屬性是方法表的屬性，則這個結構表示方法類型簽名，如果當前 Signature 屬性是字段表的屬性，則這個結構表示字段類型簽名。
18.BootstrapMethods屬性
BootstrapMethods 屬性在 JDK 1.7 發布后增加到了 Class 文件規范之中，它是一個復雜的變長屬性，位於類文件的屬性表中。這個屬性用於保存 invokedynamic 指令引用的引導方法限定符。《Java 虛擬機規范（Java SE 7 版）》規定，如果某個類文件結構的常量池中曾經出現過 CONSTANT_InvokeDynamic_info 類型的常量，那么這個類文件的屬性表中必須存在一個明確的 BootstrapMethods 屬性，另外，即使 CONSTANT_InvokeDynamic_info 類型的常量在常量池中出現過多次，類文件的屬性表中最多也只能有一個 BootstrapMethods 屬性。BootstrapMethods 屬性與 JSR-292 中的 InvokeDynamic 指令和 java.lang.invoke 包關系非常密切，要介紹這個屬性的作用，必須先弄清楚 InvokeDynamic 指令的運作原理，在此先暫時略過。
目前的 javac 暫時無法生成 InvokeDynamic 指令和 BootstrapMethods 屬性，必須通過一些非常規的手段才能使用到它們，也許在不就的將來，等 JSR-292 更加成熟一些，這種狀況就會改變。BootstrapMethods 屬性的結構見表 6-29。
BootstrapMethods 屬性中，num_bootstrap_methods 項的值給出了 bootstrap_methods[] 數組中的引導方法限定符的數量。而 bootstrap_methods[] 數組的每個成員包含了一個指向常量池 CONSTANT_MethodHandle 結構的索引值，它代表了一個引導方法，還包含了這個引導方法靜態參數uDelay序列（可能為空）。bootstrap_methods[]數組中的每個成員必須包含以下 3 項內容。
- bootstrap_method_ref：bootstrap_method_ref 項的值必須是一個對常量池的有效索引。常量池在該索引處的值必須是一個 CONSTANT_MethodHandle_info 結構。
- num_bootstrap_arguments：num_bootstrap_arguments 項的值給出了 bootstrap_arguments[] 數組成員的數量。
- bootstrap_arguments[]：bootstrap_arguments[] 數組的每個成員必須是一個對常量池的有效索引。常量池在該索引處必須是下列結構之一：CONSTANT_String_info、CONSTANT_Class_info、CONSTANT_Integer_info、CONSTANT_Long_info、CONSTANT_Float_info、CONSTANT_Double_info、CONSTANT_MethodHandle_info 或 CONSTANT_MethodType_info。