位元組碼檔案結構詳解

41uLove發表於2020-08-14

“一次編寫,到處執行(Write Once,Run Anywhere)“,這是 Java 誕生之時一個非常著名的口號。在學習 Java 之初,就瞭解到了我們所寫的.java會被編譯期編譯成.class檔案之後被 JVM 載入執行。JVM 全稱為 Java Virtual Machine,一直以為 JVM 執行 Java 程式是一件理所當然的事情,但隨著工作過程中接觸到了越來越多的基於 JVM 實現的語言如Groovy Kotlin Scala等,就深刻的理解到了 JVM 和 Java 的無關性,JVM 執行的不是 Java 程式,而是符合 JVM 規範的.class位元組碼檔案。位元組碼是各種不同平臺的虛擬機器與所有平臺都統一使用的程式儲存格式。是構成Run Anywhere 的基石。因此瞭解 Class 位元組碼檔案對於我們開發、逆向都是十分有幫助的。

Class 類檔案的結構

概述

Class檔案是一組以 8位位元組為基礎單位的二進位制流,各個資料專案嚴格按照順序緊湊地排列在 Class 檔案中,中間沒有新增任何分隔符,這使得整個 Class 檔案中儲存的內容幾乎全部是程式執行的必要資料,沒有空隙存在。當遇到需要佔用 8 位位元組以上空間的資料項時,則會按照Big-Endian的方式分割成若干個 8 位元組進行儲存。Big-Endian具體是指最高位位元組在地址最低位、最低位位元組在地址最高位的順序來儲存資料。SPARCPowerPC等處理器預設使用Big-Endian位元組儲存順序,而x86等處理器則是使用了相反的Little-Endian順序來儲存資料。因此為了Class檔案的保證平臺無關性,JVM必須對其規範統一。

Class 檔案結構

在講解Class類檔案結構之前需要先介紹兩個概念:無符號數和表。一種類似 C 語言結構體的偽結構。

  • 無符號數:基本型別資料,一 u1、u2、u4、u8 來分別代表 1 個位元組、2 個位元組、4 個位元組和 8 個位元組的無符號數。用來描述數字、索引引用、數量值或者按照UTF-8編碼構成字串值。
  • 表:由多個無符號數或者其他表作為資料項構成的複合資料型別,所有的表都習慣以_info結尾,用於描述有層次關係的複合結構的資料。

當需要描述同一型別但數量不定的多個資料時,經常會使用一個前置的容量計數器加若干個連續的資料項的形式,這時就代表此型別的集合。整個 Class檔案本質上就是一張表,其資料項如下虛擬碼所示:

ClassFile {
  u4              magic;
  u2              minor_version;
  u2              major_version;
  u2              constant_pool_count;
  cp_info         constant_pool[constant_pool_count-1];
  u2              access_flags;
  u2              this_class;
  u2              super_class;
  u2              interfaces_count;
  u2              interfaces[interfaces_count];
  u2              fields_count;
  field_info      fields[fields_count];
  u2              methods_count;
  method_info     methods[methods_count];
  u2              attributes_count;
  attribute_info  attributes[attributes_count];
}	

每項資料項的含義我們可以對照下圖參照表:

Class類檔案結構

同時我們將根據一個具體的 Java 類來分析 Class 檔案結構

public class ByteCode {
    private String username;

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }
}

其.class 檔案內容如下:

class檔案結構

使用 javap 命令可以得到反彙編程式碼:

Classfile /Users/chenjianyuan/IdeaProjects/blog/blog-web/target/test-classes/tech/techstack/blog/ByteCode.class
  Last modified 2020-8-8; size 581 bytes
  MD5 checksum 43eb79f48927d9c5bbecfa5507de0f3c
  Compiled from "ByteCode.java"
public class tech.techstack.blog.ByteCode
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #4.#21         // java/lang/Object."<init>":()V
   #2 = Fieldref           #3.#22         // tech/techstack/blog/ByteCode.username:Ljava/lang/String;
   #3 = Class              #23            // tech/techstack/blog/ByteCode
   #4 = Class              #24            // java/lang/Object
   #5 = Utf8               username
   #6 = Utf8               Ljava/lang/String;
   #7 = Utf8               <init>
   #8 = Utf8               ()V
   #9 = Utf8               Code
  #10 = Utf8               LineNumberTable
  #11 = Utf8               LocalVariableTable
  #12 = Utf8               this
  #13 = Utf8               Ltech/techstack/blog/ByteCode;
  #14 = Utf8               getUsername
  #15 = Utf8               ()Ljava/lang/String;
  #16 = Utf8               setUsername
  #17 = Utf8               (Ljava/lang/String;)V
  #18 = Utf8               MethodParameters
  #19 = Utf8               SourceFile
  #20 = Utf8               ByteCode.java
  #21 = NameAndType        #7:#8          // "<init>":()V
  #22 = NameAndType        #5:#6          // username:Ljava/lang/String;
  #23 = Utf8               tech/techstack/blog/ByteCode
  #24 = Utf8               java/lang/Object
{
  public tech.techstack.blog.ByteCode();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 7: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Ltech/techstack/blog/ByteCode;

  public java.lang.String getUsername();
    descriptor: ()Ljava/lang/String;
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: getfield      #2                  // Field username:Ljava/lang/String;
         4: areturn
      LineNumberTable:
        line 11: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Ltech/techstack/blog/ByteCode;

  public void setUsername(java.lang.String);
    descriptor: (Ljava/lang/String;)V
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: aload_1
         2: putfield      #2                  // Field username:Ljava/lang/String;
         5: return
      LineNumberTable:
        line 15: 0
        line 16: 5
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       6     0  this   Ltech/techstack/blog/ByteCode;
            0       6     1 username   Ljava/lang/String;
    MethodParameters:
      Name                           Flags
      username
}
SourceFile: "ByteCode.java"                                   

magic

每個 Class 檔案的頭 4 個位元組0xCAFEBABE稱為魔數(Magic Number),用來確定這個檔案是否為能被虛擬機器接受的 Class 檔案格式。

minor_version & major_version

第 5、6 個位元組為次版本號(minor_version),第 6、7 個位元組是主版本號(major version)上圖次版本號 00 00 轉換為 10 進製為 0,主版本號 00 34 轉換為十進位制為 52,代表 JDK 1.8。觀察反彙編程式碼也能得到次版本和主版本資訊。高版本的 JDK 向下相容低版本的 Class 檔案,但低版本不能執行高版本的 Class 檔案,即使檔案格式沒有發生任何變化,虛擬機器也拒絕執行高於其版本號的 Class 檔案。

constant_pool_count & constant_pool[]

後面緊跟著的 2 個位元組為常量池個數(constant_pool_count),然後後面緊跟 constant_pool_count 個數的常量。constant_pool_count 是從 1 開始而不是從 0 開始,是為了將 0 項空出來標識後面某些指向常量池的索引值的資料在特定情況下不引用常量池,這種情況下就可以把索引值置為 0 來表示。(除常量池計數外,對於其他型別集合包括介面索引集合、欄位表集合、方法表集合等的容量計數都與一般習慣相同,是從0開始的)

常量池(constant_pool)主要存放兩大類常量:

  • 字面量
    • 字串常量
    • final 的常量值
    • 其他類檔案的引用
  • 符號引用
    • 類和介面的全限定名
    • 欄位的名稱和描述符
    • 方法的名稱和描述符

常量池中的每一個常量都是一個常量表,常量表開始的第一位是一個u1型別的標誌位(tag),來區分常量表的型別。在JDK 1.7之前共有11種結構各不相同的表結構資料,在JDK 1.7中為了更好地支援動態語言呼叫,又額外增加了3種(CONSTANT_MethodHandle_info、CONSTANT_MethodType_info和CONSTANT_InvokeDynamic_info),14 中常量型別所代表的具體含義如下:

常量池的專案型別

常量池中的 14 種常量項的結構總表

我們對其按照字面量和符號引用型別分類的話可以入下圖所示

常量表型別分類

Class檔案中的常量池結構通過上例彙編程式碼可看出:

Constant pool:
   #1 = Methodref          #4.#21         // java/lang/Object."<init>":()V
   #2 = Fieldref           #3.#22         // tech/techstack/blog/ByteCode.username:Ljava/lang/String;
   #3 = Class              #23            // tech/techstack/blog/ByteCode
   #4 = Class              #24            // java/lang/Object
   #5 = Utf8               username
   #6 = Utf8               Ljava/lang/String;
   #7 = Utf8               <init>
   #8 = Utf8               ()V
   #9 = Utf8               Code
  #10 = Utf8               LineNumberTable
  #11 = Utf8               LocalVariableTable
  #12 = Utf8               this
  #13 = Utf8               Ltech/techstack/blog/ByteCode;
  #14 = Utf8               getUsername
  #15 = Utf8               ()Ljava/lang/String;
  #16 = Utf8               setUsername
  #17 = Utf8               (Ljava/lang/String;)V
  #18 = Utf8               MethodParameters
  #19 = Utf8               SourceFile
  #20 = Utf8               ByteCode.java
  #21 = NameAndType        #7:#8          // "<init>":()V
  #22 = NameAndType        #5:#6          // username:Ljava/lang/String;
  #23 = Utf8               tech/techstack/blog/ByteCode
  #24 = Utf8               java/lang/Object

觀察上面Class檔案00 19表示有 25 個常量,依次往後數 24(25-1)個常量則為常量池中的常量。緊隨其後的一個位元組為第一個常量表的 tag 位 0A -> 10,通過常量表型別查詢可知 10 為 CONSTANT_Methodref_info,表內資料項為u1: tag u2: class_info u2: name_and_type_index,結合Class檔案分析,這表示從第一個常量CONSTANT_Methodref_info佔用 5 個位元組,其中第一個位元組0A為標誌位,其後兩個位元組00 04 -> 4 之後兩個位元組為 class_info,緊隨 2 個位元組00 15 -> 21為 name_and_type_index。我們通過查詢彙編程式碼常量池中的一個常量表為#1 = Methodref #4.#21得出一個常量表正是方法引用,其資料項索引也是#4#21。剩下的 24 種常量分析也是如此。也是因為這 14 中常量型別各自均有自己的結構,所以說常量池是最繁瑣的資料。

小知識:

由於Class檔案中方法、欄位等都需要引用CONSTANT_Utf8_info型常量來描述名稱,所以CONSTANT_Utf8_info型常量的最大長度也就是Java中方法、欄位名的最大長度。而這裡的最大長度就是length的最大值,既u2型別能表達的最大值65535。所以Java程式中如果定義了超過64KB英文字元的變數或方法名,將會無法編譯。

access_flags

在常量池結束之後,緊接著兩個位元組代表訪問標誌(access_flag)這個標誌用於識別一些類或介面層次的訪問資訊。具體標誌位以及標誌的含義見下表:

類的訪問許可權查詢書冊

invokeSpecial 指令語義在 JDK1.0.2發生過改變,為了區別這條指令使用哪種語意,在 JDK1.0.2之後編譯出來的類的這個標誌都必須為真。

分析[Class]檔案我們得出 access_flag 為 00 21,但是查詢上表確沒有查詢到對應的標誌,這是因為 ByteCode是一個普通的 Java 類,不是介面、列舉或者註解,被public關鍵字修飾但沒有被宣告為final和abstract,並且它使用了JDK 1.2之後的編譯器進行編譯,因此它的ACC_PUBLIC、ACC_SUPER標誌應當為真,而其餘 6 個標誌應當為假,因此它的access_flags的值應為:0x0001|0x0020=0x0021。而我們通過 ByteCode 彙編程式碼檢視得到 flags: ACC_PUBLIC, ACC_SUPER 也證明了的確為上述所言。

this_class & super_class &interfaces_count & interfaces[]

類索引(this_class)、父類索引(super_class)和 介面數量(interface_count)是一個 u2型別的資料,而介面索引集合 interfaces[] 是一組 u2 型別的資料的集合。這四項資料直接確定了這個類的繼承關係。Java 不允許多繼承但是允許實現多個介面,這就為什麼super_class是一個而 interfaces 是一個集合。我們通過分析[Class]檔案可以看出 this_class 對應00 03 -> 3 從常量池中查詢 #3 對應的常量

#3 = Class              #23            // tech/techstack/blog/ByteCode
#23 = Utf8               tech/techstack/blog/ByteCode

可以看出 #3 對應的就是當前類 tech/techstack/blog/ByteCode。後面同樣為佔兩個位元組的 super_class 對應的``00 04 -> 4`從常量池中查詢出來對應的常量為

 #4 = Class              #24            // java/lang/Object
 #24 = Utf8               java/lang/Object

所以 super_class 表示的為:java/lang/Object。隨後便是 interface_count 對應的 00 00 -> 0 說明 ByteCode 沒有實現介面,因此就不存在後面的 interfaces[]。

fields_count & fields[]

欄位表(field_info)用於描述介面或者類中宣告的變數。欄位(field)包括類級變數以及例項級變數,但不包括在方法內部宣告的區域性變數。fields_count 類中 field_info 的數量。fields[] 則是 field_info 的集合。field_info 的結構如下圖所示:

field_info

欄位修飾符 access_flag 和類中的 access_flag十分相似:

欄位訪問標誌

在實際情況中,ACC_PUBLIC、ACC_PRIVATE、ACC_PROTECTED三個標誌最多隻能選擇其一,ACC_FINAL、ACC_VOLATILE不能同時選擇。介面之中的欄位必須有ACC_PUBLIC、ACC_STATIC、ACC_FINAL標誌。

繼續分析Class檔案,00 01 00 02 00 05 00 06 00 00。其中 00 01 -> 1表示 field_count,很顯然 ByteCode 類中的欄位只有一個 private String username;。 參照上表繼續取兩個位元組00 02 -> 2表示access_flag,查詢可知修飾符號為ACC_PRIVATE,繼續取兩個位元組00 05 -> 5表示 name_index,從彙編程式碼中查詢常量池#5為

#5 = Utf8               username	

繼續取兩個位元組00 006 -> 6表示descriptor_index,指向的是常量池 #6 的常量

#6 = Utf8               Ljava/lang/String;

後續的 00 00 -> 0表示attribute_count的個數,此處為 0。

名詞釋義:

  1. 全限定名和簡單名稱
    把類名中的.替換成/,連續多個全限定名時,為了不產生混淆,在使用時最後一般都會加入一個;表示全限定名結束。

  2. 方法、欄位索引描述

    方法的引數列表(包括數量、型別以及順序)和返回值。根據描述符規則,基本資料型別(byte、char、double、float、int、long、short、boolean)以及代表無返回值的void型別都用一個大寫字元來表示,而物件型別則用字元L加物件的全限定名來表示。

    • 基本資料型別

      B---->byte
      C---->char
      D---->double
      F----->float
      I------>int
      J------>long
      S------>short
      Z------>boolean
      V------->void

    • 物件型別

      String------>Ljava/lang/String;

    • 陣列型別:每一個唯獨都是用一個前置 [ 來表示

      int[] ------>[ I,

      String [][]------>[[Ljava.lang.String;

  3. 用描述符來描述方法的,先引數列表,後返回值的格式,引數列表按照嚴格的順序放在()中
    比如原始碼 String getUserInfoByIdAndName(int id,String name) 的方法描述符(I,Ljava/lang/String;)Ljava/lang/String;

methods_count & methods[]

Class檔案儲存格式中對方法的描述與對欄位的描述幾乎採用了完全一致的方式。方法表的結構如下圖所示:

Method_info

因為volatile關鍵字和transient關鍵字不能修飾方法,所以方法表的訪問標誌中沒有了ACC_VOLATILE標誌和ACC_TRANSIENT標誌。與之相對的,synchronized、native、strictfp和abstract關鍵字可以修飾方法,所以方法表的訪問標誌中增加了ACC_SYNCHRONIZED、ACC_NATIVE、ACC_STRICTFP和ACC_ABSTRACT標誌:

方法訪問標誌

同樣根據Class檔案進行分析。00 03表示 method_count 說明ByteCode類的方法有三個,根據Method_info繼續取出第一個方法的 8 個位元組00 01 00 07 00 08 00 0100 01 -> 0表示的是方法的修飾符 表示的是access_flag 為 acc_public,00 07 -> 7表示的是方法的名稱(name_index) 指向常量池中#7常量

  #7 = Utf8               <init>

表示方法為<init>的構造方法。00 08 ->8代表方法的描述符號(descriptor_index),指向常量池 #8 常量

  #8 = Utf8               ()V

表示的是無參無返回值。00 01 -> 1表示有一個方法屬性的個數為 1。

Method_info.attribute_info

根據 attribute_info 結構繼續從Class檔案中取出00 09 00 00 00 2F00 09 -> 9表示方法屬性名稱(attribute_name_index)指向常量池 #9 常量

  #9 = Utf8               Code

00 00 00 2F ->表示Code屬性的長度為 47 個位元組。(特別特別需要注意這47個位元組從Code屬性表中第三個開始也就是max_stack開始,因為此 attribute_info為 Code_attribute 本身,attribute_name_index 和 attribute_length 為 Code 的屬性)。

Code_attribute屬性表結構如下:

Code_attribute {
    u2 attribute_name_index; // 屬性名索引,常量值固定為"Code"
    u4 attribute_length;  //屬性值長度,值為整個表的長度減去6個位元組(attribute_name_index + attribute_length)
    u2 max_stack; //運算元棧深度最大值
    u2 max_locals; //區域性變數表所需的儲存空間,單位為"Slot",Slot是虛擬機器為區域性變數分配記憶體所使用的最小的單位。
    u4 code_length; // 儲存Java源程式編譯後生成的位元組碼指令,每個指令為u1型別的單位元組。虛擬機器規範中明確限制了一個方法不允許超過65535條位元組指令,實際上只用了u2長度。
    u1 code[code_length]; // 方法指向的具體指令碼
    u2 exception_table_length; // 異常表的個數
    {   u2 start_pc; // start_pc 和 end_pc 表示在 Code 陣列中的[start_pc, end_pc)處指令所丟擲的異常由這個表處理。
        u2 end_pc;
        u2 handler_pc; // 異常程式碼的開始處
        u2 catch_type; // 表示被處理流程的異常型別,指向常量池中具體的某一個異常類,catchType為 0 處理所有的異常
    } exception_table[exception_table_length]; // 異常表結構,用於存放異常資訊
    u2 attributes_count; // 屬性的個數
    attribute_info attributes[attributes_count]; // 屬性的集合
}

第一個 Code 的彙編程式碼如下:

Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 7: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Ltech/techstack/blog/ByteCode;

Tips: args_size=1是因為在任何例項方法裡面,都可以通過"this"關鍵字訪問到此方法所屬的物件。這個訪問機制對Java程式的編寫很重要,而它的實現卻非常簡單,僅僅是通過Javac編譯器編譯的時候把對this關鍵字的訪問轉變為對一個普通方法引數的訪問,然後在虛擬機器呼叫例項方法時自動傳入此引數而已。因此在例項方法的區域性變數表中至少會存在一個指向當前物件例項的區域性變數,區域性變數表中也會預留出第一個Slot位來存放物件例項的引用,方法引數值從1開始計算。

回到示例程式碼,取出 47 位 Code 值:

// _ 是本文自行新增方便表示資料項之間的間隔,Class 檔案中是不存在的
00 01  _00 01 _00 00 00 05  _2A B7 00 01 B1 _00 00  _00 02  _00 0A  _00 00 00 06  _00 01  _00 00  _00 06  _00 0B  _00 00 00 0C  _00 01 00 00 00 05 00 0C 00 0D 00 00

00 01 -> 1 表示 運算元棧(max_stack)的最大深度為 1。後面的00 01 -> 1表示區域性變數表的長度(max_locals)為 1,正好與 Code 的彙編程式碼stack=1 locals=1對應。緊接著後面 4 位00 00 00 05 -> 5表示位元組碼指令長度(code_length)為 5。繼續往後數 5 位2A B7 00 01 B1表示 JVM具體的位元組碼指令。

 0: aload_0
 1: invokespecial #1                  // Method java/lang/Object."<init>":()V
 4: return
  1. 0x2A:對應的位元組碼註記符是aload_0,作用就是把當前呼叫方法的棧幀中的區域性變數表索引位置為0的區域性變數推送到運算元棧的棧頂。

  2. 0xB7:表示是 invokespecial 呼叫父類的方法 那麼後面需要接入二個位元組表示呼叫哪個方法,所以00 01表示的是指向常量池中第一個位置為為如下結構

      1: invokespecial #1                  // Method java/lang/Object."<init>":()V
    
  3. 0xB1:對應的位元組碼指令值retrun `表示retrun void from method。

00 00表示異常表個數(exception_table_length)為 0,方法沒有丟擲異常。

00 02 -> 2表示 Code_attribute 結構中屬性表的個數為 2 個。00 0A -> 10表示 attribute_name_index 指向常量池 #10 LineNumberTable 常量。繼續後面 4 位00 00 00 06 -> 10 表示 attribute_length 即 LineNumberTable 的長度。LineNumberTable 是用來描述Java原始碼行號與位元組碼行號(位元組碼偏移量)之間的對應關係,比如我們平時 debug 某一行程式碼。其結構如下所示:

LineNumberTable_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 line_number_table_length;
    {   u2 start_pc;
        u2 line_number;	
    } line_number_table[line_number_table_length];
}

00 01 -> 1表示行號表的個數為 1,即只存在一個行號表。00 00 表示start_pc為位元組碼行號,00 06 -> 6表示原始碼行號為第 7(6+1) 行。

00 0B -> 11表示第二個屬性表對應常量池 #11 LocalVariableTable 常量。00 00 00 0C -> 12 表示 LocalVariableTable 常量的長度為 12。LocalVariableTable 屬性用於描述棧幀中區域性變數表中的變數與Java原始碼中定義的變數之間的關係。其結構如下:

LocalVariableTable_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 local_variable_table_length;
    {   u2 start_pc;
        u2 length;
        u2 name_index;
        u2 descriptor_index;
        u2 index;
    } local_variable_table[local_variable_table_length];
}

LocalVariableTable也不是執行時必需的屬性,但預設會生成到Class檔案之中,可以在Javac中分別使用-g:none-g:vars選項來取消或要求生成這項資訊。如果沒有生成這項屬性,最大的影響就是當其他人引用這個方法時,所有的引數名稱都將會丟失,IDE將會使用諸如arg0、arg1之類的佔位符代替原有的引數名,這對程式執行沒有影響,但是會對程式碼編寫帶來較大不便,而且在除錯期間無法根據引數名稱從上下文中獲得引數值。

00 01 -> 1表示本地變數表的個數 local_variable_table_length 為 1。00 00表示local_variable_table 的 start_pc 為 0,其含義為這個區域性變數的生命週期開始的位元組碼偏移量。00 05 -> 5 表示 local_variable_table 的 length 為 5,其含義為這個區域性變數作用範圍覆蓋的長度。兩者結合起來就是這個區域性變數在位元組碼之中的作用域範圍。00 0C 00 0D分別表示 name_index 和 descriptor_index,分別指向常量池中 #12 this 和 #13 Ltech/techstack/blog/ByteCode;常量。分別代表了區域性變數的名稱以及這個區域性變數的描述符。00 00 表示了這個變數在本地變數表中的index 即這個區域性變數在棧幀區域性變數表中Slot的位置。當這個變數資料型別是64位型別時(double和long),它佔用的Slot為index和index+1兩個。

attributes_count & attributes[]

屬性表(attribute_info)用於描述某些場景專有的資訊。在Class檔案、欄位表、方法表都可以攜帶自己的屬性表集合。所有的屬性都具有一下常規格式:

attribute_info { 
    u2 attribute_name_index; 
    u4 attribute_length; 
    u1 info [attribute_length]; 
}

根據The Java® Virtual Machine Specification已經增加到了 23 項。根據其用途可以分為三組:

  1. 五個屬性對於classJava虛擬機器正確解釋檔案至關重要 :

  2. 十二個屬性對於Java SE平臺的類庫正確解釋class檔案至關重要 :

  3. 六個屬性對於classJava虛擬機器或Java SE平臺的類庫對檔案的正確解釋不是至關重要的 ,但對於工具來說非常有用:

屬性彙總

按檔案位置排序預定義屬性

參考:

[1] 周志明.深入理解Java虛擬機器:JVM高階特性與最佳實踐.北京:機械工業出版社,2013.

[2] Chapter 4. Th class File Format

[3] Chapter 6. The Java Virtual Machine Instruction Set

文章首發於陳建源的部落格,歡迎訪問。
文章作者:陳建源
文章連結:https://www.techstack.tech/post/zi-jie-ma-wen-jian-jie-gou-xiang-jie/

相關文章