關(guān)于JVM和其上的byte code，網(wǎng)上其實有足夠多的資料了，我這里就簡單做個提綱和介紹，權(quán)當(dāng)記錄吧。
stack-based VM
Java byte code運行在JVM上，就像機器指令運行在物理機上，是需要遵循這個機器的指令規(guī)范的。所以認(rèn)識JVM byte code，是需要稍微了解下JVM的。JVM是一個基于棧(stack-based)的虛擬機。很久以前我還寫過類似簡單的虛擬機。
基于棧的虛擬機其操作數(shù)和指令運算的中間結(jié)果全部都在一個虛擬棧中，與之對應(yīng)的是基于寄存器(register-based)的虛擬機，其操作數(shù)和指令運算結(jié)果會存放在若干個寄存器（也就是存儲單元）里。x86機器就可以理解為基于寄存器的機器。
byte code其實和x86匯編代碼本質(zhì)一樣，無非是對應(yīng)機器制定的一堆指令，這里可以舉例說明下兩類虛擬機的不同：
# stack-based
push 1 # 壓立即數(shù)1到棧頂
push 2 # 壓立即數(shù)2到棧頂
add # 彈出棧頂2個數(shù)相加，將結(jié)果3壓到棧頂
# register-based
mov ax, 1 # 寫立即數(shù)到寄存器ax
add ax, 2 # 取ax中的值1與立即數(shù)2進(jìn)行相加，存放結(jié)果到ax
關(guān)于兩類實現(xiàn)的比較，網(wǎng)上也有不少資料，例如Dalvik 虛擬機和 Sun JVM 在架構(gòu)和執(zhí)行方面有什么本質(zhì)區(qū)別？。
至于有人說基于棧的虛擬機更利于移植，我不是很理解，因為即使是基于寄存器的實現(xiàn)，也不一定真的必須把這些寄存器映射到物理機CPU上的寄存器，使用內(nèi)存來模擬性能上跟基于棧的方式不是八九不離十嗎？
了解了JVM的這個特點，JVM上的各種指令就可以更好地理解，如果要理解JVM如何運行byte code的，那還需要了解JVM內(nèi)部的各種結(jié)構(gòu)，例如符號解析、class loader、內(nèi)存分配甚至垃圾回收等。這個以后再談。
byte-code
*.class文件就已經(jīng)是編譯好的byte code文件，就像C/C++編譯出來的目標(biāo)文件一樣，已經(jīng)是各種二進(jìn)制指令了。這個時候可以通過JDK中帶的javap工具來反匯編，以查看對應(yīng)的byte code。
// Test.java
public class Test {
public static void main(String[] args) {
int a = 0xae;
int b = 0x10;
int c = a + b;
int d = c + 1;
String s;
s = "hello";
}
}
編譯該文件：javac Test.java得到Test.class，然后javap -c Test即得到：
Compiled from "Test.java"
public class Test {
public Test();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: sipush 174 # push a short onto the stack 0xae=174
3: istore_1 # store int value into variable 1: a = 0xae
4: bipush 16 # push a byte onto the stack 0x10=16
6: istore_2 # store int value into variable 2: b = 0x10
7: iload_1 # load value from variable 1 and push onto the stack
8: iload_2
9: iadd # add two ints: a + b
10: istore_3 # c = a + b
11: iload_3
12: iconst_1 # 1
13: iadd # c + 1
14: istore 4 # d = c + 1
16: ldc #2 // String hello
18: astore 5
20: return
}
這個時候?qū)φ罩鳭VM指令表看上面的代碼，比起x86匯編淺顯易懂多了，秒懂，參考Java bytecode instruction listings。JVM中每個指令只占一個字節(jié)，操作數(shù)是變長的，所以其一條完整的指令（操作碼+操作數(shù)）也是變長的。上面每條指令前都有一個偏移，實際是按字節(jié)來偏移的。想起Lua VM的指令竟然是以bit來干的
從上面的byte code中，以x86匯編的角度來看會發(fā)現(xiàn)一些不同的東西：
局部變量竟是以索引來區(qū)分：istore_1 寫第一個局部變量，istore_2寫第二個局部變量，第4個局部變量則需要用操作數(shù)來指定了：istore 4
函數(shù)調(diào)用invokespecial #1竟然也是類似的索引，這里調(diào)用的是Object基類構(gòu)造函數(shù)
常量字符串也是類似的索引：ldc #2
*.class中是不是也分了常量數(shù)據(jù)段和代碼段呢
以上需要我們進(jìn)一步了解*.class文件的格式。
class file format
class 文件格式網(wǎng)上也有講得很詳細(xì)的了，例如這篇Java Class文件詳解。整個class文件完全可以用以下結(jié)構(gòu)來描述：
ClassFile {
u4 magic; //魔數(shù)
u2 minor_version; //次版本號
u2 major_version; //主版本號
u2 constant_pool_count; //常量池大小
cp_info constant_pool[constant_pool_count-1]; //常量池
u2 access_flags; //類和接口層次的訪問標(biāo)志（通過|運算得到）
u2 this_class; //類索引（指向常量池中的類常量）
u2 super_class; //父類索引（指向常量池中的類常量）
u2 interfaces_count; //接口索引計數(shù)器
u2 interfaces[interfaces_count]; //接口索引集合
u2 fields_count; //字段數(shù)量計數(shù)器
field_info fields[fields_count]; //字段表集合
u2 methods_count; //方法數(shù)量計數(shù)器
method_info methods[methods_count]; //方法表集合
u2 attributes_count; //屬性個數(shù)
attribute_info attributes[attributes_count]; //屬性表
}
這明顯已經(jīng)不是以區(qū)段來分的格式了，上面提到的函數(shù)索引、常量字符串索引，都是保存在constant_pool常量池中。常量池中存儲了很多信息，包括：
各種字面常量，例如字符串
類、數(shù)據(jù)成員、接口引用
常量池的索引從1開始。對于上面例子Test.java，可以使用javap -v Test來查看其中的常量池，例如：
Constant pool:
#1 = Methodref #4.#13 // java/lang/Object."<init>":()V
#2 = String #14 // hello
#3 = Class #15 // Test
#4 = Class #16 // java/lang/Object
#5 = Utf8 <init>
#6 = Utf8 ()V
#7 = Utf8 Code
#8 = Utf8 LineNumberTable
#9 = Utf8 main
#10 = Utf8 ([Ljava/lang/String;)V
#11 = Utf8 SourceFile
#12 = Utf8 Test.java
#13 = NameAndType #5:#6 // "<init>":()V
#14 = Utf8 hello
#15 = Utf8 Test
#16 = Utf8 java/lang/Object
每一個類都會有一個常量池。
summary
要想了解JVM運行byte code，還需要了解更多JVM本身的東西，例如符號解析，內(nèi)存管理等，可參考：
JVM Internals
Understanding JVM Internals
更多信息請查看IT技術(shù)專欄
公眾號
事業(yè)單位
當(dāng)前位置：
公考類
招聘類
各類考試