java虛擬機學習筆記

學習java虛擬機已經很久了，最近有空，于是將我所知道的一些關于java虛擬機的知識寫出來。首先當做是重新復習一下，其次是給想了解java虛擬機的朋友一些參考。筆記內容大量參看《深入理解java虛擬機》這本書。

一、虛擬機內存組成模塊

java虛擬機規范中規定了以下組成部分：程序計數器、虛擬機方法棧、本地方法棧（Hotspot中將虛擬機方法棧和本地方法棧合并成方法棧）、java堆、方法區（java8以后將方法區移到了虛擬機外）、運行常量池。

另外java虛擬機還可以額外分配直接內存，不過這不屬于java虛擬機內存組成。整體組成如下圖：

程序計數器

java虛擬機之所以被稱為虛擬機是因為它模仿物理機運行實現的，它的程序計數器也類似于操作系統中的程序計數器，是線程私有的，作用是存儲線程將要執行的下一個操作指令（java模仿物理機，也自己實現了多種操作指令）。程序計數器只占用了一小塊內存區域。

方法棧和本地方法棧

java中每一次方法調用都對應了方法棧的進棧和出站操作，方法棧中每一個棧幀都對應著java代碼中相應的方法調用，棧幀中局部變量表存儲了基礎數據類型（boolean、byte、char、int、long、float、double、）和reference（reference包括兩種：句柄和指針，各自有各自的好處，使用句柄則在改變對象位置時不改變局部變量表里的引用只用改變句柄本身的指針即可，指針的優點則是查詢效率快）。

這里有個知識點，實際上Java中的數組是Java虛擬機動態生成的一個對象，不屬于基礎數據類型，我們常用的數組的length屬性其實就是它的對象的一個public屬性。

java堆

java堆是虛擬機中最大的內存組成部分，用來存儲程序執行中產生的對象（不包括常量、靜態常量引用的對象）。java堆會因為垃圾回收以及對應的垃圾回收器的不同而采用不用的劃分方式，但整體還是劃分為新生代和老年代兩個部分。新生代又分為eden區（伊甸區）和survivor區域（幸存區域）。java默認Eden區域是survivor區域的8倍大小（垃圾回收復制算法執行過程統計出來的合適倍數）。不過存在survivor區域又分為兩塊相同大小的survivor區域：from?survivor區域和to?survivor區域，作為輪轉備用。簡單的說，java程序運行中對象就是Eden區域survivor區域和老年代中創建、清理、復制、整理。

方法區

方法區用于存儲虛擬機加載的類信息、常量、靜態常量等，也被稱為永久代。Hotspot在java8之前用永久代來實現方法區，java8后永久代被移出虛擬機內存，使用native?memory存儲。

運行時常量池

運行時常量池屬于方法區的一部分，用來存儲常量的值，存儲內容分為兩種：字面量和符號引用。這個的理解需要結合Class類的前端編譯來解讀。在虛擬機加載類的時候比如類的名字、字段的名字、常量等的值需要存儲下來，而且會頻繁使用。Java中的基本數據類型和String類型都可以在虛擬機加載類的時候理解為虛擬機可以描述的值，并不是程序員自己定義的對象。這些值是需要并可以存儲在虛擬機中并供后期使用的，這些值便是運行時常量池中的字面量。另外如string.intern()方法也可以在運行期間將一個String的值放到常量池中并返回常量池的引用，只不過這個不是在虛擬機加載類時候放入的。常量池中另一種數據類型是符號引用，這個跟class的結構也是相關的，前端編譯階段，對class結構的描述過程中，一個字面量是可以反復被使用的，于是便可以給字面量編一個索引，在符號引用中引用這個索引去得到值，當然，符號引用本身也會被索引供其他符號引用使用。這個便是常量池中的內容，需要結合對class結構的了解才能更好的理解為什么會有常量池以及常量池中 存儲的內容，不能錯誤的直接理解為我們在開發時在class中自己定義的 “常量”，它包含了我們通常理解的“常量”，但遠不止如此。另外，對于我自己常說的自己定義的“常量”，只有static 和 final修飾的基礎類型和string類型才屬于constantvalue，對象不屬于constantvalue。對象的內存是分配在Java堆中，常量是分配在方法區中的運行時常量池中的。舉一個常量的特殊性的例子：如在使用ClassA.CONSTANT_VALUEA時，這個時候虛擬機使用的是常量，假如這個時候ClassA還沒有被加載，使用這個ClassA.CONSTANT_VALUEA的值時是不會觸發ClassA的加載的。

直接內存

java直接allocat出來的內存。NIO使用的緩沖區就是直接內存。

二、虛擬機的垃圾回收

虛擬機的垃圾回收基本可等同于對Java堆的垃圾回收。

虛擬機中判斷對象是否死亡的算法——可達性算法

可達性算法的描述非常簡單 ：對象是否被GC Roots所直接引用，是則存活；是否被GC Roots直接引用的對象所直接或通過其他對象間接引用，是則存活；不滿足則被標記為死亡。

以下是從網上找的可達性算法示意：

GC Roots包含：

1.虛擬機棧

2.方法區中的靜態屬性

3.方法區中的常量

4.本地方法棧

對象的finalize方法

finalize方法經常會在面試中被問到，它提供了類似C/C++中析構函數的功能，當Java中的對象將要被回收時，如果對象有重寫finalize方法，那么finalize方法將會被調用一次，當第二次要被回收時則不會被觸發調用。我們可以嘗試在finalize方法中拯救對象本身不被虛擬機回收，例如將對象被GC Roots引用，那樣便可以使對象免于被回收。但是finalize方法并不能一定保證這種操作一定能成功，成功的關鍵在于finalize方法中的代碼執行的要比虛擬機垃圾回收要快，因此finalize方法中拯救對象本身不具備確定性。finalize方法所Java早期為贏得使用者的產物，建議不使用，它完全能被finally和其他方式代替。

垃圾回收算法——標記清除算法

下圖是從網上找的標記清除算法的示意圖，其原理非常簡單：首先對對象的可達性進行標記，然后清除掉不可達的對象。

標記清除的算法的問題是清除之后留下的可用的存儲空間非常零碎，當我們需要一個比較大的存儲空間來存儲大對象時，這將是個災難。虛擬機不直接使用標記清除算法來回收垃圾，但是標記清除算法是其他優化過的算法的基礎。

垃圾回收算法——復制算法

復制算法的原理也很簡單：將內存劃分為兩塊相同大小的區域，只使用其中一塊，當進行垃圾回收時，將還存活的對象移至另一塊內存中，本身則全部清除掉，這樣就不會產生內存碎片。

下圖是復制算法的示意圖,圖片來自網上：

我們可以看出，復制算法是基于標記清除算法的思想進行的，復制算法的缺陷是浪費了太多內存，Java虛擬機使用復制算法時當然不會直接這樣去做。實際上復制算法是java堆中新生代的基本算法思想（實際上并沒有這么直接使用）。

Java虛擬機根據對象的存活時間不同的特點將Java堆分成新生代和老年代。新生代的對象“朝生夕死”，存活時間短，內存重新分配頻繁，適合使用復制算法進行垃圾回收。Java虛擬機將新生代劃分為eden區和survivor區（survivor區域有兩塊，一塊from區域，一塊to區域，輪轉備用），對應復制算法需要的兩塊內存區域。因為經過垃圾回收后剩下的對象其實是少數，所以survivor區域并不需要和eden區域一樣大，那樣太浪費內存空間，虛擬機默認的大小是eden區域是survivor區域的8倍大小，虛擬機啟動時支持配置。

另外，復制算法只是基礎，虛擬的不同回收器實際執行時還進行了優化。

垃圾回收算法——標記整理算法

標記整理算法也是基于標記清除算法實現的，不同點是在標記之后不是將對象直接清除，而是將存活對象前移，清除存活對象內存空間之外的內存空間。

下圖也是從網上找的示意圖：

當內存大對象多，且對象頻繁產生死亡的時候，效率是非常低下的，因此不適合新生代的垃圾回收。但是老年代的對象存活率高，內存相對較小，很適合標記整理算法。

三種算法總結：標記清除算法是其他兩種算法以及其他優化過的垃圾回收算法的基礎，復制算法適用于新生代，標記整理算法適用于老年代，實際上，Java虛擬機也確實是分代進行垃圾回收的。

概念——STW

STW:stop the world。Java虛擬機進行垃圾回收時是需要中斷工作線程的執行的，期間Java程序出現了短暫的停頓。當然，現在虛擬機對垃圾回收的不斷優化，幾乎可以忽略STW時間了。

垃圾回收器——CMS（current mark sweep）回收器

從名字就可以看出CMS回收器是基于標記清除算法的回收器，它的運作過程分為四步驟：

1.初始標記

初始標記的作用是標記出那些被GC Roots直接引用的對象。這個期間或產生短暫的STW時間

2.并發標記

并發標記是同時和用戶線程執行的，標記出被所有被引用的對象。不會產生STW。

3.重新標記

并發標記的時間相對長一些，這個期間可能用于用戶線程的操作，并發標記的結果可能已經跟實際產生了偏差，重新標記便是糾正這個偏差的。期間會停止用戶線程，產生STW。

4.并發清除

并發清除就很好理解了，就是垃圾的清除工作是和用戶線程一起進行的，不會導致用戶線程的停頓。

在進行以上四步后并不能保證所有的垃圾都被清除掉了，因為用戶線程是在并發進行的。遺漏的垃圾對象需要依賴于下次垃圾回收進行清除。

CMS回收器是多線程并發執行的，因此是對CPU敏感的，比較占用CPU資源。

CMS回收器因為是基于標記清除算法的，單純的進行這種算法也會產生內存碎片。當無法分配大的內存空間時，會導致Full GC來整理內存空間。

垃圾回收器——G1回收器

G1回收器和CMS在過程上有很多類似之處，只是稍有不同，但是兩個回收器的目的和實現方式時完全不一樣的。

G1回收器更專注于對于CPU資源的使用，充分發揮現代多核超線程CPU的優勢。G1收集器不能確切的劃分為標記清除算法、復制算法或者標記整理算法，它在原來新生代老年代的基礎上將內存劃分為多個區域Region，新生代和老年代都是由多個Region組成的集合。同時，它會跟各個Region垃圾的多少對各個Region進行優先級劃分，這種將內存化整為零的做法避免來對全部內存的操作。

G1回收器的實現細節遠比上面描述的要復雜，但是其過程也可以劃分為以下四步：

1.初始標記

2.并發標記

3.最終標記

4.篩選回收

前面3個步驟都和CMS很類似，只不過是分Region進行的，篩選回收則是對所有Region進行篩選，只選擇對那些有必要的Region進行垃圾回收。

Minor GC 和 Major GC / Full GC

這三種稱呼其實有點混亂，而且也只是對Java虛擬機垃圾回收的一種思考角度，不能代表虛擬機的垃圾回收算法的劃分。

Minor GC 和 Major GC、Full GC的分界還是很清晰的。Minor GC是指對年新生代的垃圾回收動作，它的執行頻率非常頻繁，回收速度也比較快。

Major GC是指對老年代的劃分，一般會伴隨一次Minor GC，一般速度較慢。Full GC可以理解為對整個堆的垃圾回收，其實和Major GC語意有點重復，它的另一個語意是產生了STW。

對象的一生

我們現在已經知道，從整體來說，對象是被分配在新生代和老年代中，新生代又被分為eden區域和survivo區域。當一個創建時，它優先是被分配在新生代的eden區域的，但是大的對象（默認3M,可以在JVM啟動時設置）直接會被分配到老年代。JVM會為每個對象的“年齡”計數。當存在于eden區域的對象經歷過一次垃圾回收后，它就被移到survivor區域，同時它的年齡就被+1，當它的年齡達到15（虛擬機啟動時可通過參數配置）的時候就會被移到老年代。另外，虛擬機會survivor區域的大小是否充足，如果內存不足，對象也將直接移至老年代。

三、類文件結構

在分析類文件結構前，我們先寫一個簡單的類：

package?me.wxh.clazzstd;
public?class?TestClass?{
????private?int?m;
????public?static?String?CLASS_VARIABLE?=?"我是類變量";
????public?final?static?String?CONSTANT_VALUE?=?"我才是常量";
????public?final?static?int?CONSTANT_INT?=?1;
????public?int?inc()?{
????????return?m?+?1;
????}
????public?static?void?main(String[]?args)?throws?Exception{
????????System.out.println(CLASS_VARIABLE);
????????System.out.println(CONSTANT_VALUE);
????????System.out.println(CONSTANT_INT);
????????catInt("wuxuehai");
????}
????public?static?Integer?catInt(String?intValue)?throws?Exception{
????????try?{
????????????return?Integer.parseInt(intValue);
????????}
????????catch?(NumberFormatException?e)?{
????????????return?0;
????????}
????????finally?{
????????????System.out.println("finally?塊執行");
????????}
????}
}

然后我們使用javap -verbose 命令查看它的class文件結構，如下：

/System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/javap?-verbose?TestClass.class
Classfile?/Users/wuxuehai/IdeaProjects/algorithm/target/classes/me/wxh/clazzstd/TestClass.class
??Last?modified?2019-4-24;?size?1459?bytes
??MD5?checksum?fdc48a22d072179c43e64b1a57226ef1
??Compiled?from?"TestClass.java"
public?class?me.wxh.clazzstd.TestClass
??minor?version:?0
??major?version:?49
??flags:?ACC_PUBLIC,?ACC_SUPER
Constant?pool:
???#1?=?Methodref??????????#16.#48????????//?java/lang/Object."<init>":()V
???#2?=?Fieldref???????????#6.#49?????????//?me/wxh/clazzstd/TestClass.m:I
???#3?=?Fieldref???????????#50.#51????????//?java/lang/System.out:Ljava/io/PrintStream;
???#4?=?Fieldref???????????#6.#52?????????//?me/wxh/clazzstd/TestClass.CLASS_VARIABLE:Ljava/lang/String;
???#5?=?Methodref??????????#53.#54????????//?java/io/PrintStream.println:(Ljava/lang/String;)V
???#6?=?Class??????????????#55????????????//?me/wxh/clazzstd/TestClass
???#7?=?String?????????????#56????????????//?我才是常量
???#8?=?Methodref??????????#53.#57????????//?java/io/PrintStream.println:(I)V
???#9?=?String?????????????#58????????????//?wuxuehai
??#10?=?Methodref??????????#6.#59?????????//?me/wxh/clazzstd/TestClass.catInt:(Ljava/lang/String;)Ljava/lang/Integer;
??#11?=?Methodref??????????#60.#61????????//?java/lang/Integer.parseInt:(Ljava/lang/String;)I
??#12?=?Methodref??????????#60.#62????????//?java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
??#13?=?String?????????????#63????????????//?finally?塊執行
??#14?=?Class??????????????#64????????????//?java/lang/NumberFormatException
??#15?=?String?????????????#65????????????//?我是類變量
??#16?=?Class??????????????#66????????????//?java/lang/Object
??#17?=?Utf8???????????????m
??#18?=?Utf8???????????????I
??#19?=?Utf8???????????????CLASS_VARIABLE
??#20?=?Utf8???????????????Ljava/lang/String;
??#21?=?Utf8???????????????CONSTANT_VALUE
??#22?=?Utf8???????????????ConstantValue
??#23?=?Utf8???????????????CONSTANT_INT
??#24?=?Integer????????????1
??#25?=?Utf8???????????????<init>
??#26?=?Utf8???????????????()V
??#27?=?Utf8???????????????Code
??#28?=?Utf8???????????????LineNumberTable
??#29?=?Utf8???????????????LocalVariableTable
??#30?=?Utf8???????????????this
??#31?=?Utf8???????????????Lme/wxh/clazzstd/TestClass;
??#32?=?Utf8???????????????inc
??#33?=?Utf8???????????????()I
??#34?=?Utf8???????????????main
??#35?=?Utf8???????????????([Ljava/lang/String;)V
??#36?=?Utf8???????????????args
??#37?=?Utf8???????????????[Ljava/lang/String;
??#38?=?Utf8???????????????Exceptions
??#39?=?Class??????????????#67????????????//?java/lang/Exception
??#40?=?Utf8???????????????catInt
??#41?=?Utf8???????????????(Ljava/lang/String;)Ljava/lang/Integer;
??#42?=?Utf8???????????????e
??#43?=?Utf8???????????????Ljava/lang/NumberFormatException;
??#44?=?Utf8???????????????intValue
??#45?=?Utf8???????????????<clinit>
??#46?=?Utf8???????????????SourceFile
??#47?=?Utf8???????????????TestClass.java
??#48?=?NameAndType????????#25:#26????????//?"<init>":()V
??#49?=?NameAndType????????#17:#18????????//?m:I
??#50?=?Class??????????????#68????????????//?java/lang/System
??#51?=?NameAndType????????#69:#70????????//?out:Ljava/io/PrintStream;
??#52?=?NameAndType????????#19:#20????????//?CLASS_VARIABLE:Ljava/lang/String;
??#53?=?Class??????????????#71????????????//?java/io/PrintStream
??#54?=?NameAndType????????#72:#73????????//?println:(Ljava/lang/String;)V
??#55?=?Utf8???????????????me/wxh/clazzstd/TestClass
??#56?=?Utf8???????????????我才是常量
??#57?=?NameAndType????????#72:#74????????//?println:(I)V
??#58?=?Utf8???????????????wuxuehai
??#59?=?NameAndType????????#40:#41????????//?catInt:(Ljava/lang/String;)Ljava/lang/Integer;
??#60?=?Class??????????????#75????????????//?java/lang/Integer
??#61?=?NameAndType????????#76:#77????????//?parseInt:(Ljava/lang/String;)I
??#62?=?NameAndType????????#78:#79????????//?valueOf:(I)Ljava/lang/Integer;
??#63?=?Utf8???????????????finally?塊執行
??#64?=?Utf8???????????????java/lang/NumberFormatException
??#65?=?Utf8???????????????我是類變量
??#66?=?Utf8???????????????java/lang/Object
??#67?=?Utf8???????????????java/lang/Exception
??#68?=?Utf8???????????????java/lang/System
??#69?=?Utf8???????????????out
??#70?=?Utf8???????????????Ljava/io/PrintStream;
??#71?=?Utf8???????????????java/io/PrintStream
??#72?=?Utf8???????????????println
??#73?=?Utf8???????????????(Ljava/lang/String;)V
??#74?=?Utf8???????????????(I)V
??#75?=?Utf8???????????????java/lang/Integer
??#76?=?Utf8???????????????parseInt
??#77?=?Utf8???????????????(Ljava/lang/String;)I
??#78?=?Utf8???????????????valueOf
??#79?=?Utf8???????????????(I)Ljava/lang/Integer;
{
??public?static?java.lang.String?CLASS_VARIABLE;
????descriptor:?Ljava/lang/String;
????flags:?ACC_PUBLIC,?ACC_STATIC
??public?static?final?java.lang.String?CONSTANT_VALUE;
????descriptor:?Ljava/lang/String;
????flags:?ACC_PUBLIC,?ACC_STATIC,?ACC_FINAL
????ConstantValue:?String?我才是常量
??public?static?final?int?CONSTANT_INT;
????descriptor:?I
????flags:?ACC_PUBLIC,?ACC_STATIC,?ACC_FINAL
????ConstantValue:?int?1
??public?me.wxh.clazzstd.TestClass();
????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?3:?0
??????LocalVariableTable:
????????Start??Length??Slot??Name???Signature
????????????0???????5?????0??this???Lme/wxh/clazzstd/TestClass;
??public?int?inc();
????descriptor:?()I
????flags:?ACC_PUBLIC
????Code:
??????stack=2,?locals=1,?args_size=1
?????????0:?aload_0
?????????1:?getfield??????#2??????????????????//?Field?m:I
?????????4:?iconst_1
?????????5:?iadd
?????????6:?ireturn
??????LineNumberTable:
????????line?14:?0
??????LocalVariableTable:
????????Start??Length??Slot??Name???Signature
????????????0???????7?????0??this???Lme/wxh/clazzstd/TestClass;
??public?static?void?main(java.lang.String[])?throws?java.lang.Exception;
????descriptor:?([Ljava/lang/String;)V
????flags:?ACC_PUBLIC,?ACC_STATIC
????Code:
??????stack=2,?locals=1,?args_size=1
?????????0:?getstatic?????#3??????????????????//?Field?java/lang/System.out:Ljava/io/PrintStream;
?????????3:?getstatic?????#4??????????????????//?Field?CLASS_VARIABLE:Ljava/lang/String;
?????????6:?invokevirtual?#5??????????????????//?Method?java/io/PrintStream.println:(Ljava/lang/String;)V
?????????9:?getstatic?????#3??????????????????//?Field?java/lang/System.out:Ljava/io/PrintStream;
????????12:?ldc???????????#7??????????????????//?String?我才是常量
????????14:?invokevirtual?#5??????????????????//?Method?java/io/PrintStream.println:(Ljava/lang/String;)V
????????17:?getstatic?????#3??????????????????//?Field?java/lang/System.out:Ljava/io/PrintStream;
????????20:?iconst_1
????????21:?invokevirtual?#8??????????????????//?Method?java/io/PrintStream.println:(I)V
????????24:?ldc???????????#9??????????????????//?String?wuxuehai
????????26:?invokestatic??#10?????????????????//?Method?catInt:(Ljava/lang/String;)Ljava/lang/Integer;
????????29:?pop
????????30:?return
??????LineNumberTable:
????????line?18:?0
????????line?19:?9
????????line?20:?17
????????line?21:?24
????????line?22:?30
??????LocalVariableTable:
????????Start??Length??Slot??Name???Signature
????????????0??????31?????0??args???[Ljava/lang/String;
????Exceptions:
??????throws?java.lang.Exception
??public?static?java.lang.Integer?catInt(java.lang.String)?throws?java.lang.Exception;
????descriptor:?(Ljava/lang/String;)Ljava/lang/Integer;
????flags:?ACC_PUBLIC,?ACC_STATIC
????Code:
??????stack=2,?locals=4,?args_size=1
?????????0:?aload_0
?????????1:?invokestatic??#11?????????????????//?Method?java/lang/Integer.parseInt:(Ljava/lang/String;)I
?????????4:?invokestatic??#12?????????????????//?Method?java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
?????????7:?astore_1
?????????8:?getstatic?????#3??????????????????//?Field?java/lang/System.out:Ljava/io/PrintStream;
????????11:?ldc???????????#13?????????????????//?String?finally?塊執行
????????13:?invokevirtual?#5??????????????????//?Method?java/io/PrintStream.println:(Ljava/lang/String;)V
????????16:?aload_1
????????17:?areturn
????????18:?astore_1
????????19:?iconst_0
????????20:?invokestatic??#12?????????????????//?Method?java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
????????23:?astore_2
????????24:?getstatic?????#3??????????????????//?Field?java/lang/System.out:Ljava/io/PrintStream;
????????27:?ldc???????????#13?????????????????//?String?finally?塊執行
????????29:?invokevirtual?#5??????????????????//?Method?java/io/PrintStream.println:(Ljava/lang/String;)V
????????32:?aload_2
????????33:?areturn
????????34:?astore_3
????????35:?getstatic?????#3??????????????????//?Field?java/lang/System.out:Ljava/io/PrintStream;
????????38:?ldc???????????#13?????????????????//?String?finally?塊執行
????????40:?invokevirtual?#5??????????????????//?Method?java/io/PrintStream.println:(Ljava/lang/String;)V
????????43:?aload_3
????????44:?athrow
??????Exception?table:
?????????from????to??target?type
?????????????0?????8????18???Class?java/lang/NumberFormatException
?????????????0?????8????34???any
????????????18????24????34???any
??????LineNumberTable:
????????line?26:?0
????????line?32:?8
????????line?26:?16
????????line?28:?18
????????line?29:?19
????????line?32:?24
????????line?29:?32
????????line?32:?34
????????line?33:?43
??????LocalVariableTable:
????????Start??Length??Slot??Name???Signature
???????????19??????15?????1?????e???Ljava/lang/NumberFormatException;
????????????0??????45?????0?intValue???Ljava/lang/String;
????Exceptions:
??????throws?java.lang.Exception
??static?{};
????descriptor:?()V
????flags:?ACC_STATIC
????Code:
??????stack=1,?locals=0,?args_size=0
?????????0:?ldc???????????#15?????????????????//?String?我是類變量
?????????2:?putstatic?????#4??????????????????//?Field?CLASS_VARIABLE:Ljava/lang/String;
?????????5:?return
??????LineNumberTable:
????????line?7:?0
}
SourceFile:?"TestClass.java"

接下開，我們利用這兩個文件來簡單解釋下類文件的結構，順便會涉及到部分class加載的過程解析和虛擬機內存模型的知識。實際上，我們開發過程中并不太可能需要去閱讀class文件，但了解class文件的結構有助于我們理解和驗證Java虛擬機的執行的過程結構。

常量池——constant pool

類的開始是一些基礎的描述，相信并不需要過多的解讀，真正需要理解的地方便是從constant pool這里開始，constant pool其實便是我經常所說的常量池。

下面我們來解讀下常量池里內容。

常量池中每一行便是一個常量，最左邊的#1、#2、#3……是常量的索引。常量分為字面量和符號引用兩種，符號引用會引用其他符號引用和字面量最終也可以解析成一個固定格式的值。

?“=” 號后的值如“Utf8”、“NameAndType”等都是常量的類型描述，常量的類型有很多種，需要了解更多的可結合資料和書籍去了解，我們只能注重于理解。在這里舉一個例子：索引#7的常量是一個String類型的常量，它的第三列是#56，這時我們看第二張圖，索引#56的常量是一個“Utf8”類型的常量，表示一個Uft8編碼的文本，也就是我們代碼里的“public final static String CONSTANT_VALUE = "我才是常量”;”這行中的值，這里編譯器是把“我才是常量”這個值生成了一個字面量，然后被#7引用，定義成了一個String類型的符號引用。

第三列是常量的值，如果是字面量，則會是“我才是常量”、1….這樣的值，如果是符號引用，則會是對其他常量的索引引用。

最后“//”后面的是對常量的注釋，如果是字面量，則沒有這一列，如果是符號引用則備注了符號引用的實際值。

常量池在虛擬機中非常重要，javac編譯（前端編譯）出的字節碼中代碼中大量引用到常量池中的值，如我們的代碼中：

這里的字節碼指令中#3、#4….等等都是對常量池中的常量的引用。而前端編譯是為了后面的類加載提供的基礎的。

字段表

字段表緊跟常量池之后，包含了我們在類中定義的類變量和實例變量，在我們的代碼中如下：

我們可以看到它描述了我們定義的CLASS_VARIABLE、CONSTANT_VALUE、CONSTANT_INT 這三個字段，表示出了它們的訪問權限、類型、返回值等等。同時在我們的常量池中，我們也可以看到它們的字段名被分別定義成#19、#21、#23這三個Utf8常量。

比較下CLASS_VARIABLE和CONSTANT_VALUE、CONSTANT_INT的區別，我們可以發現后面兩個變量多了一個ConstantValue屬性，這就是我們之前在介紹虛擬機內存組成模塊時介紹常量池時所說的，只有同時被static和final修飾的才是常量，這一點很重要，常量的賦值是虛擬機自動執行，而類變量的賦值是在<clinit>（類初始化）方法中執行，實例變量是在<init>（對象初始化）方法中執行，這就導致我們在其他類中使用常量時，不會觸發類的加載。

方法表

方法表存在于字段表之后，我們可以注意到，正如我們才學Java時所知道的一樣，當我們沒有寫構造方法時，編譯器會為我們默認實現一個構造方法（雖然當時不知道原理，但確實是這樣的）：

下面我們用我們代碼中的main函數來解析下方法表中方法的構造。main函數的代碼如下：

它經過前端編譯后的代碼如下：

我們來對應著看，首先在字節碼的最上部描述出了方法的名稱、參數、返回信息、拋出的異常、訪問權限等等，這些都非常的直觀，我們不多做贅述。

Code屬性

Code屬性是方法表里核心信息，它將我們方法里的代碼描述成Java的字節碼指令，然后在虛擬機中執行這些指令便是我們代碼的執行（實際上還需要翻譯成匯編指令，翻譯行為又分為解釋執行和編譯執行兩種）。指令后不帶參數的都是對操作數棧（后面會解釋到）棧頂元素的操作，帶參數的指令需要結合常量池的索引翻譯成完整的指令。invoke*這樣的指令是對方法的調用，不過方法分很多種，invokevirtual指令是帶參數的，但也就是對棧頂對象實例方法的調用，調用棧頂實例的指定方法（我們這里是System.out的println方法，System.out就是我們的棧頂的實例）。這里又個很重要的知識點，invokevirtual這樣的調用形式，雖然我們的指令形式都是一樣的，但是我們的棧頂對象是可變的，如果我們父類和子類都有同樣名字的方法，那么在棧頂的對象是父類還是子類將決定我們調用的實際方法的不同，實際上，這便是Java中多態的實現基礎！

簡單介紹下這里的指令：

getstatic? ? 訪問類字段

invokevirtual?? ?? 調用虛方法，這只是方法調用的一種，后面我們會知道所有的方法調用指令。

invokestatic? ? 調用靜態方法

iconst_1? ? 將int類型的常量1加載到操作數棧

ldc? ? 將一個常量加載到操作數棧

return? ? 方法返回void

LineNumberTable

不知道大家有沒有想過這樣的問題：為什么我們在debug時候，開發工具能夠找到我們對應的代碼的源碼呢？！有時候我們的class文件和我們的源碼版本不一樣，那debug時候就亂跑一通？！實際上就是這個LineNumberTable造成的，它的功能非常簡單，將方法中的指令的行號和源碼中的行號進行對應，這一點我們從截圖中看它的形式便能夠非常輕松的理。在進行前端編譯的時候我們可以選擇是否保留LineNumberTable，javac -g:none 選擇不保留，javac -g:lines選擇保留，當然不保留時，我們就無法從源碼中設置斷點了。

LocalVariableTable

這是個非常重要的部分，它描述了運行時局部變量表中的變量和源碼中變量的關系，直觀的給我們展示了Java虛擬機運行時的組成。前面我們在說Java虛擬機內存組成的時候提到過Java虛擬機棧，它的棧貞的每一個元素便包含了一個局部變量表，方法的調用對應著虛擬機棧的進棧操作，調用結束后返回對應著一個出棧操作。這是我們Java虛擬機執行的系統的核心之一！不過這里不是運行時的局部變量表，現在只是前端編譯階段，但是正如我們開始時所說的那樣，我們可以從class文件的結構中窺探Java虛擬機運行時的樣貌。它和LineNumberTable一樣，也不是Java虛擬機執行時必須的，可以在前端編譯時選擇javac -g:none或者javac -g:vars來選擇取消或者生成這個部分，但是Java虛擬機運行時一定會有對應的局部變量表。

這里有個知識點：如果方法是實例方法，那么局部變量表的第一個變量就是this，代表實例本身，這也是為何我們可以在實例方法中可以使用this關鍵字的原因。

字段表和方法表中還包含了很多其他很重要的屬性，但是我們無法寫完整，主要原因是：

1.我也不是很了解～

2.那太多啦！

我們只說了幾個能很好反應虛擬機運行機制的部分，能夠理解虛擬機的運行就達到了我們的目的了。

Java中的異常控制流程——try catch finally在字節碼中的體現

下面我們還是先看一下我們的示例代碼中的方法：

然后是它轉成字節碼后的代碼：

Java中的異常控制是通過Exception table實現的，以我們代碼中的Exception table為例，它定義了try catch finally代碼塊執行的三個流程：

????1.0-8行指令執行，當出現java/lang/NumberFormatException異常時跳轉到18行的指令。

????2.0-8行指令執行，當出現任何異常時，跳轉至34行指令。

????3.18-24行的指令執行，當出現任何異常時，跳轉至34行指令。

正好對應了try catch finally的語言。

Java中方法的調用指令

invokevirtual 調用虛方法，指調用實例的方法（公共的方法）。

invokeinterface 調用接口方法，在運行時找到實現接口方法的對象，調用對象的合適（方法的重載重寫）方法執行。

invokespecial? ? 調用特殊的實例方法：實例初始化方法、私有方法、父方法

invokestatic? ? 調用類方法

invkedynamic? ? 這個比較特殊，是對動態語言的支持，并且在Java編譯器中無法看到

Java中方法的調用指令很重要，它搭建出了Java用語言方法調用的基本特性。

四、Java虛擬機類加載機制

類加載的過程

java虛擬機加載類的過程可以細分為以下7個階段：

加載（Class Loading）

這個過程是指：

1.使用類的全限定名來獲取此類的二進制流。

2.將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構。

3.生成一個代表這個類的lava.lang.Class對象，class對象雖然是一個對象，但是會存在方法區中（HotSpot虛擬機就是這么做的）。

Java虛擬機對類的加載是比較封閉的，字節流的獲取是我們少數能控制的部分，因此也產生了很多我們熟知的技術：

• 從zip包中獲取，如我們熟知的jar、ear、war包

• 從網絡中獲取，如已經沒落的Applet技術

• 代碼動態生成的，如jdk的動態代理cglib技術

• 由其他文件生成，如jsp（jsp生成的字節流的加載器有些特殊，每一次jsp文件的加載變會生成一個新的加載器，這個加載器生成的目的就是為了被廢棄）

假如我們看了jdk的類加載器的代碼，就會知道，實際上，每個類加載器都會有一個定義自己管轄的目錄的構造方法，然后在這個路徑下取字節流。

這里有一個特殊的情況，那就是對于數組的加載，我們知道數組不屬于java的基本數據類型，也不是一個簡單的引用類型，沒有對應的Class，實際上數組對象是由Java虛擬機直接創建的。數組去掉維度后的類型如果是引用類型則會觸發這個引用類型的加載數組類型的可見性和引用類型保持一致；如果是基礎數據類型，則可見性為public。

驗證

這個階段的目的就是為了保證Class字節流中包含的信息符合虛擬機的要求，并且不會危害到虛擬機的安全。這個過程我覺得只要知道大概意思即可，沒有必要過多研究。

準備

準備階段是正式為類變量分配內存并設置類變量的初始值的階段，類變量如果是基本數據類型或者String類型的數據，則內存劃分是在方法區中進行的。這里我們仍然以我們的之前的字節碼文件證明一下：

在我們的字節碼文件中的最后部分，我們能看到一個static{}代碼塊，實際上這個便是虛擬機生成的<clinit>（class init）方法里的指令，用來初始化類。我們可以看到，首先第一條指令ldc是從常量池中獲取“我是類變量”這個常量，然后putstatic賦值給#4 （me/wxh/clazzstd/TestClass.CLASS_VARIABLE:Ljava/lang/String;）這個類變量。不過這個是初始化階段的代碼，我們只是用來證明下這種數據類型的類變量的內存劃分的位置。

對于實例變量類型的類變量，自然不用說，它一定是在Java堆中劃分內存的。

非引用類型的類變量的初始值都是0值，但是我們還是需要注意，常量和類變量的區別，同時被static和final修飾的變量也就是常量的初始值會被直接賦值為對應的ConstantValue的值，這個我們在前面已經說到過了。

解析

解析是將常量池中的符號引用翻譯為直接引用的過程。在之前我們已經知道，常量池中包含兩種類型的數據：字面量和符號引用。字面量包含基本數據類型和String類型的數值，符號引用引用開其他符號引用或者字面量。但是虛擬機執行不會在執行的時候去翻譯這些符號引用，而是在解析階段就將其翻譯為直接引用，即句柄或者指針。

解析過程的觸發是在虛擬機指令操作符號引用時觸發。

類變量的初始化

根據我的理解，解析和初始化過程是交替進行的，應該沒有嚴格的先后順序。

再次看一下我們之前的示例的字節碼的最后部分：

在之前的準備階段，我們已經提到，虛擬機會自動生成<clinit>方法，這個方法的作用是初始化類的，它里面的指令內容包含兩種，順序由在源碼中出現的先后順序決定：

1. 對類變量進行賦值，這個我們在實例代碼中已經可以清楚的看到。

2. 第二種是源碼中的staic代碼塊中的內容將會被生成到<clinit>方法中。

虛擬機啟動時并不會立刻將所有代碼里的所有類都加載到虛擬機中，而是在運行時動態加載的，當運行中遇到下面情況時，虛擬機會加載類：

1. 遇到new、getstatic、putstatic、invokestatic這4條指令時，如果類沒有加載則出發類的加載過程。注意：使用static final修飾的常量時，并不是使用getstatic指令，并不會觸發類的加載。

2. 使用java.lang.reflect包的方法進行反射調用時，如果類沒有被初始化

3. 初始化一個類時，發現其父類還沒有被初始化，則先初始化其父類

4. 虛擬機啟動時main方法所在的類會被優先初始化。

5. Java支持動態語言時解析出的REF_getstatic、REF_putstatic、REF_invokestatic的方法句柄對應的類沒有初始化則先進行初始化。

關于<clinit>方法：

1. 首先它不是必要的，當一個類中既沒有類變量，也沒有static代碼塊時，Java虛擬機不會產生<clinit>方法

2. 當執行一個類的<clinit>方法時，如果父類的<clinit>方法還沒有被執行，那么就先執行父類的<clinit>方法。

3. <clinit>方法在并發執行的時候時加鎖的。

   
   

類加載器：

首先，類加載器的作用是完成類的加載動作的，即類加載的第一個階段。Java中可以擁有很多個類加載器，其中有虛擬機提供的，也會有自定義的類加載器。每一個類加載器都有其類命名空間，當一個Class的字節碼由不同類加載器加載時，那么它們就是不相同的類。

Java中的類加載器和雙親委派模型

虛擬機的類加載器可分為兩種：一種是虛擬機提供的加載器——啟動加載器，由C++實現；另一種是由Java語言實現的類加載器，它們都繼承于抽象類java.lang.ClassLoader。

從另一個維度，按功能劃分，我們可以將Java中默認提供的類加載器分為以下幾種：

1. 啟動類加載器（Bootstrap ClassLoader），它的作用就是將javahome\lib目錄下或者指定的-Xbootclasspath目錄下的類庫按名字查找并加載到虛擬機中。比如我們的rt.jar，如果改名叫其他名字，那么，即使它在以上目錄下，那么它也不能正常被加載。它是由C++實現的，是Java虛擬機的組成部分。

2. 擴展類加載器（ExtClassLoader），它是用來加載“java.ext.dirs”系統變量指定目錄下的類庫的。它是由Java語言實現的。

3. 應用加載器（AppClassLoader），它和ExtClassLoader一樣都是在sun.misc.Launcher類中的內部類，負責加載classpath中的指定的類庫。

4. 自定義的類加載器。我們自己用java代碼實現的類加載器。

   
   

加載器的雙親委派模型

如果一個類加載器收到了類加載的請求，它首先不會嘗試自己去加載這個類，而是委派給父類加載器去完成，所以每一次加載請求會先傳到頂部的啟動加載器，當父類加載器無法完成加載請求時子類加載器才會去嘗試加載類。加載器雙親委派模型如下：

假如我們自己實現了一個java.lang.Object類，因為有雙親委派模型的存在，類加載請求最終會被轉到啟動加載器中去，而啟動加載器只會在自己管轄的路徑里去查找類，所以我們無法自己寫一個Object類放到classpath中去替換jdk提供的Object類（實際上我們可以下載Openjdk去修改代碼并編譯）。

五、虛擬機字節碼執行引擎

?? ??? ?大學時候我們學習編譯原理時候，我們知道程序執行分為兩種：解釋執行和編譯執行。解釋執行不提前編譯代碼，通過解釋器去執行代碼；編譯執行則預先編譯好代碼產生本地代碼去執行，而Java程序運行中時時進行編譯和優化的技術叫做JIT。我們將java代碼編譯成class文件的動作被稱為前端編譯，后期將class文件的內容編譯為本地文件的工作叫做即時編譯（JIT）。總體來說，解釋執行的有點是啟動速度快，而編譯執行的優點則是執行效率快。

?? ?? ? 前面我們在說Java內存模塊的時候提到過虛擬機棧，它是Java虛擬機執行的根本構造，它是屬于線程的，每個線程都擁有自己的方法棧。虛擬機棧中的一個棧幀對應了一次方法的調用，所有方法的調用在一起便是我們程序的執行！?Java中運行時內存模型是工作內存——主內存的模型，主內存負責存儲數據，工作內存從主內存獲取數據的副本在工作內存中運算，結束后將變量的值存儲到主內存 。虛擬機棧就是我們的工作內存，下圖展示了棧幀的基本結構：

這個圖簡單的示意了虛擬機棧的結構，實際上虛擬機棧實現的時候，相鄰棧幀的操作數棧和局部變量表會設計成相交的，以實現方法調用的返回值。

局部變量表

?? ??? ?這個我們在解釋class文件結構時便介紹過，在此我們可以前后照應。局部變量表的作用是存放方法的參數和方法內定義的局部變量，局部變量表的最小單位以solt計算，每一個slot中存放著boolean、byte、char、short、int、float、reference和returnAddress類型的數據，long和double類型的數據則分配兩個連續的slot存儲。reference就是我們通常說的引用，它分為句柄和指針兩種。returnAdress現在不怎么使用了，最初被用來實現異常處理，現在已經被異常表代替。

?? ?? ?如果我們讀過《effectiv java》這本書，應該會對書中有一章有所印象，這章提到要盡量最小化變量的作用域，在這里我們可以得到印證。因為局部變量表的每個slot是可以復用的減少變量的作用域不僅可以減少局部變量表的長度，而且確定不用的變量會被垃圾回收器回收掉。

?? ?? 如果方法是實例方法，那么局部變量表的第0位存放則是這個實例的reference，也就是我們一直用的this！

操作數棧

? ? ??前面我們解釋class文件方法中的Code屬性時介紹過，字節碼指令有的是不帶參數的，而不帶參數的指令則操作的目標則是操作數棧中的數據，例如字節碼中的iadd則是將操作數棧棧頂的兩個int數據相加，ldc指令則是將常量放入操作數棧的棧頂。

方法的調用

Java中方法的調用指令有以下5種：

1. invokevirtual 調用虛方法，指調用實例的方法（公共的方法）。

2. invokeinterface 調用接口方法，在運行時找到實現接口方法的對象，調用對象的合適（方法的重載重寫）方法執行。

3. invokespecial? ? 調用特殊的實例方法：實例初始化方法、私有方法、父方法

4. invokestatic? ? 調用類方法

5. invkedynamic? ? 這個比較特殊，是對動態語言的支持，支持了lambda表達式的語法。

在我們之前說的類加載過程的解釋過程中，invokespecial和invokestatic指令帶的符號引用已經被翻譯成方法的入口地址，它們的調用時固定的，因此它們被稱為非虛方法的調用。invokeinterface和invokevirtual調用的時候需要根據操作數棧棧頂的對象來獲取調用方法的實際入口地址，它們則被稱為虛方法的調用。

方法的靜態分派

接下來，我們用書上的例子來解釋下方法的靜態分派：

這個例子的執行結果大家應該沒有什么異議的，不論方法的實際類型時什么，虛擬機執行的結果都是“hello，guy”。這是因為兩個sayHello方法調用的方法在編譯期間已經確定，我們傳入的參數woman和man的靜態類型（Static Type）都是Human，因此調用的都是參數類型為Human的方法。

我們來看下這個代碼編譯后調用sayHello方法時的字節碼指令：

從后面對#13符號引用的備注我們可以很明顯的看到調用的方法在前端編譯期已經被確定是參數類型是Human的sayHello方法。這個跟我們后面要說的動態分配可以做個對比，可以很清晰地從字節碼層面理解動態分配和靜態分配的區別。

方法的靜態分配按照靜態類型分配是它叫做靜態分配的主要原因，不過我覺得這個分配是在編譯期已經確定了的也是它叫做這個名字的另一個主要原因吧。

關于方法的重載overload，靜態分配會在編譯期決定了到底調用哪個版本的代碼，不過如果方法的參數個數一致，編譯期在確定版本的時候會按照一定的規則來確定死亡（這個規則比較難用語言描述，編譯器會選擇最合適的版本），例如上面的例子，我們把參數類型為Man的sayHello方法注釋掉，然后main方法里man的類型聲明為Man，則代碼執行的結果會是這樣的：

這里，我們把參數類型為Man的方法已經注釋掉了，按照靜態類型分配，已經無法分配到參數類型為Man的方法了，于是編譯期給我們分配到了參數類型為Human的方法。

再用《深入理解Java虛擬機》這本書上的例子來更好地演示下編譯期在靜態分配上做的最合適的選擇：

這里我們重寫了很多sayHello方法，當我們調用時使用’a’作為參數時，編譯器給我們選擇的最優方法是sayHello(char arg)，這時候我們看編譯后的結果：

方法調用選擇的是sayHello:(C)V，這里的C便是char類型。但是當我們把sayHello(char arg)這個方法注釋掉，那么編譯的結果就會是這樣：

編譯期把同一段代碼編譯成了sayHello:(I)V這個不一樣的結果（I表示int），有興趣的可以逐個注釋掉這些方法，看看編譯器選擇的優先級。

方法的動態分派

前面說的靜態分派是前端編譯期已經決定的，動態分派則不是，它是在虛擬機運行期間對象的實際類型來確定執行的方法的，這也是它名字的由來。

下面我們還是用《深入理解Java虛擬機》這本書上的例子結合編譯后的字節碼來演示下什么叫動態分派：

注意：我們這里的sayHello方法都是沒有參數的，或者說參數一樣的，無法通過靜態分配區分出。

相信任何Java程序員對這段代碼的結果應該都沒有異議，這非常面向對象～ 那么接下來我們需要從Java虛擬機的角度來考慮，為什么結果會是這樣的！首先，我們還是來看一下這段代碼中main函數編譯后的字節碼：

?? ?從字節碼的LineNumberTable中可以看出，源碼中三句sayHello方法——23行、24行、26行的調用分別對應著Code屬性里的16-17行、20-21行、32-33行。這里的一行源碼被編譯成了兩行字節碼指令，這是為什么能？

?? ?我們之前說過Java虛擬機運行時內存模型時說過操作數棧這個概念，它存儲了方法執行過程中的臨時數據。aload_<n>這個字節碼指令的意思是將局部變量表中的第n個slot中局部變量加載到操作數棧中，對應代碼里，就是將我們聲明并實例化的man、woman的變量引用存儲到操作數棧中（man是第一個生聲明的變量，n是1，woman是第二個聲明的變量，n是2）。緊接著是invokevirtual指令，它是對實例方法的調用，但我們只看到了它的參數只有一個對方法的描述，卻沒有對象，對的，它執行的對象就是操作數棧棧頂的變量。

這個時候，我們看到的對方法的描述都是“Method me/wxh/clazzstd/DynamicDispatch$Human.sayHello:()V”，但是卻因為棧頂元素的不同，執行了不同的方法。實際上我們在介紹靜態分配時舉的第一個例子編譯的字節碼也是invokevirtual，不過那里是同一個對象，()V里面的參數類型限定符的不同，這里是限定符相同，對象不同。

?? ?

?? ?對于invokevirtual指令，它的解析過程大致是這樣的：

1. 找到棧頂的第一個元素所指的對象的實際類型，記做C

2. 如果在類型C中找到常量的中描述符和簡單名稱都相符的方法，則進行方法的權限檢驗，如果通過則返回這個方法的直接引用，查找過程結束；如果不通過則返回IllealAccessError

3. 否則按照繼承關系從下往上對C的各個父類進行第2步查找

4. 如果最終沒有找到合適的方法，則拋出java.lang.AstractMethodError

?? ?

? ? 順便我們利用這個代碼在驗證下我們之前說的Java虛擬機運行時的java虛擬機棧的概念，代碼里我們new里三個對象，我們拿第一個new的man的對象來解釋下，代碼很簡單：Human man = new Man();它編譯后的字節碼指令對應為：

我們來解釋下這四行字節碼：

• 0行：new指令創建me/wxh/clazzstd/DynamicDispatch$Man類的實例，這個時候操作數棧棧頂會有一個這個實例的引用。

• 3行：dup指令將棧頂的元素復制一份再壓回棧頂，這個時候操作數棧有兩個一個一樣的me/wxh/clazzstd/DynamicDispatch$Man類的實例的引用

• 4行：invokespecial指令調用類實例的<init>方法，操作數棧棧頂出棧，只剩下一個me/wxh/clazzstd/DynamicDispatch$Man類的實例的引用

• 7行：astore_1指令將操作數棧棧頂的變量存儲到局部變量表的第1位（實例方法的第0位是this保留的，可能靜態方法也保留了只不過沒有值，這個有待考證，不過不影響我們介紹流程），這個時候操作數棧第二個me/wxh/clazzstd/DynamicDispatch$Man類的實例的引用也出棧了。

花了這么多時間來舉這個例子，我覺得是非常值得的，通過它，我們知道了局部變量表和操作數棧是如何協同工作的了

動態語言支持

首先對動態語言的理解：拿javascript舉例，變量的聲明都是“var”，變量是不明確類型的，變量的值才具有類型，方法的調用在運行時才去判斷。

之前說過的invokedynamic指令是java對動態語言的支持，但是在java7及以下版本是看不到invokedynamic，并且invokedynamic指令設計的目的也是提高Java虛擬機對動態語言的支持，使得其他在java虛擬機上能支持動態語言的執行。

java7的動態語言支持——java.lang.invoke.MethodHandle

下面是一個java.lang.invoke.MethodHandle的使用例子，來自于《深入理解java虛擬機》這本書：

但是這個類的字節碼中我們無法找到invokedynamic指令，有興趣的可以用javap看一下，不需要用java7去編譯。

java8后的lambda表達式

下面我們用一個lambda表達式的例子來看一下invokedynamic指令是什么樣子的。

源代碼：

javap查看字節碼：

第一個紅圈對應的是

Arrays.sort(names, new Comparator<String>() {

??? @Override

??? public int compare(String o1, String o2) {

??????? return o1.compareTo(o2);

??? }

});

這個代碼，我們可以清楚看到，產生了一個LambdaTest$1這個匿名內部類，并new了一個它的對象。

第二個紅圈對應的代碼是

list.forEach((String name) -> {

??? System.out.println(name);

});

這個用lambda表達式產生的字節碼，這里我可以看出，編譯器產生的是一個invokedynamic指令。

五、虛擬機運行期間優化

?? ??? ?首先我們得有個大的概念：虛擬機的優化分為兩個階段，第一個階段是前端編譯階段，這個期間Java編譯器將我們的源碼編譯成字節碼，字節碼與平臺無關，為后期進一步解釋編譯提供基礎；第二個階段是運行時解釋/編譯，這時候Java虛擬機會進一步將字節碼翻譯成機器碼后執行。

學過編譯原理，我們都知道，程序的執行分為解釋執行和編譯執行兩種：解釋執行是使用解釋器執行，不提前編譯代碼，優點是啟動速度快、省去編譯的時間，缺點是解釋執行的效率相對編譯執行會慢很多；編譯執行則是提前將代碼編譯成機器碼后執行，相對于解釋執行的缺點就是啟動慢，優點則是執行效率高。編譯器在前端編譯期間就在生成字節碼上進行了優化，不過這個不是我們要討論的內容。

主流的Java虛擬機都同時包含解釋器和編譯期，并不會單一的使用解釋執行或者編譯器。虛擬機會統計代碼的執行頻度，當代碼反復執行后，虛擬機就知道這段代碼是一段“熱點代碼”，這時候就會對這段代碼進行重新優化編譯，這種技術就是JIT（Just In Time Compiler）技術。

熱點代碼：

• 多次被調用的方法

• 多次被執行的循環體里的代碼塊

  
  

client模式和server模式

?? ??? ?Java虛擬機（HotSpot）在啟動的時候可以選擇-client以客戶端模式啟動，-server以服務端模式啟動。

?? ?? ? Hotspot虛擬機中包含了兩個編譯器，分別稱為Client Compiler和Server Compiler，也分別被簡稱為C1和C2編譯器。虛擬機中一般是默認采用解釋器和編譯器混合執行的策略。虛擬機啟動時可以通過-Xint指定為只使用解釋執行，那么虛擬機將完全使用解釋執行；-Xcomp指定為編譯執行，這時候虛擬機優先采用編譯器執行程序，但是在編譯器無法進行的情況下進行解釋執行。

?? ?? ? Server模式在虛擬機中被默認開啟。分層編譯分為：

• 第0層，程序解釋執行，解釋器不開啟性能監控，可觸發第1層編譯

• 第1層，被稱為C1編譯，將字節碼編譯為本地代碼，進行簡單、可靠的優化，如有必要將加入性能監控的邏輯。

• 第2層，也被稱為C2編譯，也是將字節碼轉位本地代碼，但是會啟用一些耗時比較長的優化，甚至會根據性能監控i 信息進行一些不可靠的激進優化。

  
  

六、Java的內存模型（JMM）與線程

前面我們已經提到過java的工作空間和主內存的概念，下圖示意里線程、工作內存和主內存的之間的交互關系：

?? ??? ?這個內存模型實現了并發變成的基礎，非常類似于物理機的內存模型。線程在使用主內存中的數據時，需要先將變量從主內存中拷貝到工作內存中形成變量的副本，然后在工作內存中進行賦值、讀取等操作。這種內存模型使線程對數據的操作都是在工作內存中進行的，虛擬機能夠將工作內存優先存儲于比物理內存更快的高速緩存和寄存器中，從而提高了程序的運行速度。

?? ?? ? 但是我們思考下，這樣做也會產生一個不好的后果：我們同時會有主內存中變量的多個副本，多個線程對器進行讀取、賦值操作也就造成，某些副本的值已經失去失效，然后用失效的值進行運算，再將錯誤的結果寫入主內存，這都導致了我們常說的“多線程安全”問題。正式因為出于這個考慮虛擬機則在主內存和工作內存進行交互時定義了一些列規定和協議，正確使用則能保證相對的線程安全（沒有絕對的線程安全）。

Java內存模型定義了一些基本操作，這些操作都是原子的、不可再分的（操作不代表指令）：

• lock（鎖定）：用于主內存的變量，它把變量標識為一條線程獨占的狀態。

• Unlock（解鎖）：作用于主內存的變量，它把一個處于鎖定狀態的變量釋放出來，釋放后的變量才可以被其他線程鎖定。

• read（讀取）：作用于主內存的變量，它把一個變量的值傳輸到線程的工作內存中，以便隨后的load動作使用。

• load（載入）：作用于工作內存的變量，它把read操作從主內存中得到的變量值放入工作內存變量副本中。

• use（使用）：作用于工作內存的變量，它把工作內存中的一個變量的值傳輸給執行引擎，每當虛擬機遇到一個需要使用到變量的值的字節碼指令時將執行這個操作。

• assign（賦值）：作用于工作內存中的變量，它把一個從執行引擎中接收到的值賦工作內存中的變量，每當虛擬機遇到一個給變量賦值的字節碼時執行這個操作。

• store（存儲）：作用于工作內存的變量，它將工作中一個變量的值傳輸到主內存中，以便隨后的write操作使用。

• write（寫入）：作用于主內存的變量，它把store操作從工作內存中得到的變量的值放入到主工作內存中。

?? ??? ?這些操作本身的意義非常好理解，無非是圍繞著變量的鎖定解鎖、變量值復制、傳遞、賦值過程進行定義的。圍繞著這些定義的基本操作，Java虛擬機規范提出了必須要遵守的規則，然后通過這些規則限定，保重了數據在工作內存和主內存之間交互的線程安全性。

volatile修飾符的語意

volatile修飾符保證了變量讀寫的多線程可見性

? ? 基于上面的知識，我們考慮一下這種情況：在多線程環境下，我們一個線程A從主內存中read、load了一個變量的值，然后另一個線程B store、wtrite修改了主內存中這個變量的值，這時候已經拿了變量值的線程A在use變量副本的值的時候是不知道線程B對變量的賦值操作的。但是如果我們使用volatile來修飾我們的變量，那么過程就不是這樣了，虛擬機規范中對volatile修飾的變量作出了以下規定：

1. 線程對volitale變量的副本的load、use操作必須是連續在一起的，也就是說每次使用volitale變量時，肯定是從主內存中最新同步的。

2. 線程對工作內存中的副本變量進行sotre、write操作前的前一條操作必須是assign操作，也就是說，賦值完必須馬上存儲到主內存中去。

由于這兩條規定，虛擬機就保證了線程執行過程對volitale變量的賦值和使用時都是類似于原子的操作，也就保證了它多線程讀寫的可見性！

volatile修飾符修飾的代碼不會被指令重排序

我們知道，Java虛擬機在運行期間會進行代碼的優化，中間會對結果不變的多個指令操作進行重新排序，但是這可能對其執行的先后順序進行了修改，如果我們的線程B的代碼依賴于線程A指令執行的先后順序而產生的結果，那么就可能導致產生錯誤的判斷結果，這個是非常可怕的。如果使用了voatile修飾一個變量，那么虛擬機將不會對volatile修飾的變量進行指令重排序優化。注意：線程A代碼依賴于自身代碼指令的先后順序而產生的結果，那么即使進行了重新排序，那么也不會影響判斷，這是重排序優化自己做的限制。