愛(ài)鋒貝

標(biāo)題: JVM核心知識(shí)體系 [打印本頁(yè)]
作者: 希慕阿巴阿巴    時(shí)間: 2023-2-8 17:06
標(biāo)題: JVM核心知識(shí)體系
1.問(wèn)題

2.關(guān)鍵詞

類結(jié)構(gòu)，類加載器，加載，鏈接，初始化，雙親委派，熱部署，隔離，堆，棧，方法區(qū)，計(jì)數(shù)器，內(nèi)存回收，執(zhí)行引擎，調(diào)優(yōu)工具，JVMTI，JDWP，JDI，熱替換，字節(jié)碼，ASM，CGLIB，DCEVM
3.全文概要（文末有驚喜，PC端閱讀代碼更佳）

作為三大工業(yè)級(jí)別語(yǔ)言之一的JAVA如此受企業(yè)青睞有加，離不開(kāi)她背后JVM的默默復(fù)出。只是由于JAVA過(guò)于成功以至于我們常常忘了JVM平臺(tái)上還運(yùn)行著像Clojure/Groovy/Kotlin/Scala/JRuby/Jython這樣的語(yǔ)言。我們享受著JVM帶來(lái)跨平臺(tái)“一次編譯到處執(zhí)行”臺(tái)的便利和自動(dòng)內(nèi)存回收的安逸。本文從JVM的最小元素類的結(jié)構(gòu)出發(fā)，介紹類加載器的工作原理和應(yīng)用場(chǎng)景，思考類加載器存在的意義。進(jìn)而描述JVM邏輯內(nèi)存的分布和管理方式，同時(shí)列舉常用的JVM調(diào)優(yōu)工具和使用方法，最后介紹高級(jí)特性JDPA框架和字節(jié)碼增強(qiáng)技術(shù)，實(shí)現(xiàn)熱替換。從微觀到宏觀，從靜態(tài)到動(dòng)態(tài)，從基礎(chǔ)到高階介紹JVM的知識(shí)體系。
4.類的裝載

4.1類的結(jié)構(gòu)

我們知道不只JAVA文本文件，像Clojure/Groovy/Kotlin/Scala這些文本文件也同樣會(huì)經(jīng)過(guò)JDK的編譯器編程成class文件。進(jìn)入到JVM領(lǐng)域后，其實(shí)就跟JAVA沒(méi)什么關(guān)系了，JVM只認(rèn)得class文件，那么我們需要先了解class這個(gè)黑箱里面包含的是什么東西。
JVM規(guī)范嚴(yán)格定義了CLASS文件的格式，有嚴(yán)格的數(shù)據(jù)結(jié)構(gòu)，下面我們可以觀察一個(gè)簡(jiǎn)單CLASS文件包含的字段和數(shù)據(jù)類型。
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];
}
詳細(xì)的描述我們可以從JVM規(guī)范說(shuō)明書(shū)里面查閱類文件格式(https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html)，類的整體布局如下圖展示的。

(, 下載次數(shù): 7)

在我的理解，我想把每個(gè)CLASS文件類別成一個(gè)一個(gè)的數(shù)據(jù)庫(kù)，里面包含的常量池/類索引/屬性表集合就像數(shù)據(jù)庫(kù)的表，而且表之間也有關(guān)聯(lián)，常量池則存放著其他表所需要的所有字面量。了解完類的數(shù)據(jù)結(jié)構(gòu)后，我們需要來(lái)觀察JVM是如何使用這些從硬盤上或者網(wǎng)絡(luò)傳輸過(guò)來(lái)的CLASS文件。
4.2加載機(jī)制

4.2.1類的入口

在我們探究JVM如何使用CLASS文件之前，我們快速回憶一下編寫(xiě)好的C語(yǔ)言文件是如何執(zhí)行的？我們從C的HelloWorld入手看看先。
#include <stdio.h>

int main() {
   /* my first program in C */
   printf("Hello, World! \n");
   return 0;
}
編輯完保存為hello.c文本文件，然后安裝gcc編譯器（GNU C/C++）
$ gcc hello.c
$ ./a.out
Hello, World!
這個(gè)過(guò)程就是gcc編譯器將hello.c文本文件編譯成機(jī)器指令集，然后讀取到內(nèi)存直接在計(jì)算機(jī)的CPU運(yùn)行。從操作系統(tǒng)層面看的話，就是一個(gè)進(jìn)程的啟動(dòng)到結(jié)束的生命周期。
下面我們看JAVA是怎么運(yùn)行的。學(xué)習(xí)JAVA開(kāi)發(fā)的第一件事就是先下載JDK安裝包，安裝完配置好環(huán)境變量，然后寫(xiě)一個(gè)名字為helloWorld的類，然后編譯執(zhí)行，我們來(lái)觀察一下發(fā)生了什么事情？
先看源碼，有夠簡(jiǎn)單了吧。
package com.zooncool.example.theory.jvm;
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("my classLoader is " + HelloWorld.class.getClassLoader());
    }
}
編譯執(zhí)行
$ javac src/main/java/com/zooncool/example/theory/jvm/HelloWorld.java
$ java -cp src/main/java/ com.zooncool.example.theory.jvm.HelloWorld
my classLoader is sun.misc.Launcher$AppClassLoader@2a139a55
對(duì)比C語(yǔ)言在命令行直接運(yùn)行編譯后的a.out二進(jìn)制文件，JAVA的則是在命令行執(zhí)行java classFile，從命令的區(qū)別我們知道操作系統(tǒng)啟動(dòng)的是java進(jìn)程，而HelloWorld類只是命令行的入?yún)?，在操作系統(tǒng)來(lái)看java也就是一個(gè)普通的應(yīng)用進(jìn)程而已，而這個(gè)進(jìn)程就是JVM的執(zhí)行形態(tài)（JVM靜態(tài)就是硬盤里JDK包下的二進(jìn)制文件集合）。
學(xué)習(xí)過(guò)JAVA的都知道入口方法是public static void main(String[] args)，缺一不可，那我猜執(zhí)行java命令時(shí)JVM對(duì)該入口方法做了唯一驗(yàn)證，通過(guò)了才允許啟動(dòng)JVM進(jìn)程，下面我們來(lái)看這個(gè)入口方法有啥特點(diǎn)。
說(shuō)名入口方法需要被public修飾，當(dāng)然JVM調(diào)用main方法是底層的JNI方法調(diào)用不受修飾符影響。
我們是從類對(duì)象調(diào)用而不是類創(chuàng)建的對(duì)象才調(diào)用，索引需要靜態(tài)修飾
void返回類型讓JVM調(diào)用后無(wú)需關(guān)心調(diào)用者的使用情況，執(zhí)行完就停止，簡(jiǎn)化JVM的設(shè)計(jì)。
這個(gè)我也不清楚，可能是約定俗成吧，畢竟C/C++也是用main方法的。
說(shuō)了這么多main方法的規(guī)則，其實(shí)我們關(guān)心的只有兩點(diǎn)：
關(guān)于JVM如何使用HelloWorld下文我們會(huì)詳細(xì)講到。
我們知道JVM是由C/C++語(yǔ)言實(shí)現(xiàn)的，那么JVM跟CLASS打交道則需要JNI(Java Native Interface)這座橋梁，當(dāng)我們?cè)诿钚袌?zhí)行java時(shí)，由C/C++實(shí)現(xiàn)的java應(yīng)用通過(guò)JNI找到了HelloWorld里面符合規(guī)范的main方法，然后開(kāi)始調(diào)用。我們來(lái)看下java命令的源碼就知道了
/*
* Get the application's main class.
*/
if (jarfile != 0) {
mainClassName = GetMainClassName(env, jarfile);
... ...
mainClass = LoadClass(env, classname);
if(mainClass == NULL) { /* exception occured */
... ...
/* Get the application's main method */
mainID = (*env)->GetStaticMethodID(env, mainClass, "main", "([Ljava/lang/String;)V");
... ...
{/* Make sure the main method is public */
jint mods;
jmethodID mid;
jobject obj = (*env)->ToReflectedMethod(env, mainClass, mainID, JNI_TRUE);
... ...
/* Build argument array */
mainArgs = NewPlatformStringArray(env, argv, argc);
if (mainArgs == NULL) {
ReportExceptionDescription(env);
goto leave;
}
/* Invoke main method. */
(*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
4.2.2類加載器

上一節(jié)我們留了一個(gè)核心的環(huán)節(jié)，就是JVM在執(zhí)行類的入口之前，首先得找到類再然后再把類裝到JVM實(shí)例里面，也即是JVM進(jìn)程維護(hù)的內(nèi)存區(qū)域內(nèi)。我們當(dāng)然知道是一個(gè)叫做類加載器的工具把類加載到JVM實(shí)例里面，拋開(kāi)細(xì)節(jié)從操作系統(tǒng)層面觀察，那么就是JVM實(shí)例在運(yùn)行過(guò)程中通過(guò)IO從硬盤或者網(wǎng)絡(luò)讀取CLASS二進(jìn)制文件，然后在JVM管轄的內(nèi)存區(qū)域存放對(duì)應(yīng)的文件。我們目前還不知道類加載器的實(shí)現(xiàn)，但是我們從功能上判斷無(wú)非就是讀取文件到內(nèi)存，這個(gè)是很普通也很簡(jiǎn)單的操作。
如果類加載器是C/C++實(shí)現(xiàn)的話，那么大概就是如下代碼就可以實(shí)現(xiàn)
char *fgets( char *buf, int n, FILE *fp );
如果是JAVA實(shí)現(xiàn)，那么也很簡(jiǎn)單
InputStream f = new FileInputStream("theory/jvm/HelloWorld.class");
從操作系統(tǒng)層面看的話，如果只是加載，以上代碼就足以把類文件加載到JVM內(nèi)存里面了。但是結(jié)果就是亂糟糟的把一堆毫無(wú)秩序的類文件往內(nèi)存里面扔，沒(méi)有良好的管理也沒(méi)法用，所以需要我們需要設(shè)計(jì)一套規(guī)則來(lái)管理存放內(nèi)存里面的CLASS文件，我們稱為類加載的設(shè)計(jì)模式或者類加載機(jī)制，這個(gè)下文會(huì)重點(diǎn)解釋。
根據(jù)官網(wǎng)的定義A class loader is an object that is responsible for loading classes. 類加載器就是負(fù)責(zé)加載類的。我們知道啟動(dòng)JVM的時(shí)候會(huì)把JRE默認(rèn)的一些類加載到內(nèi)存，這部分類使用的加載器是JVM默認(rèn)內(nèi)置的由C/C++實(shí)現(xiàn)的，比如我們上文加載的HelloWorld.class。但是內(nèi)置的類加載器有明確的范圍限定，也就是只能加載指定路徑下的jar包(類文件的集合)。如果只是加載JRE的類，那可玩的花樣就少很多，JRE只是提供了底層所需的類，更多的業(yè)務(wù)需要我們從外部加載類來(lái)支持，所以我們需要指定新的規(guī)則，以方便我們加載外部路徑的類文件。
系統(tǒng)默認(rèn)加載器

通過(guò)上文運(yùn)行HelloWorld我們知道JVM系統(tǒng)默認(rèn)加載的類大改是1560個(gè)，如下圖

(, 下載次數(shù): 6)

自定義類加載器

內(nèi)置類加載器只加載了最少需要的核心JAVA基礎(chǔ)類和環(huán)境變量下的類，但是我們應(yīng)用往往需要依賴第三方中間件來(lái)完成額外的業(yè)務(wù)，那么如何把它們的類加載進(jìn)來(lái)就顯得格外重要了。幸好JVM提供了自定義類加載器，可以很方便的完成自定義操作，最終目的也是把外部的類文件加載到JVM內(nèi)存。通過(guò)繼承ClassLoader類并且復(fù)寫(xiě)findClass和loadClass方法就可以達(dá)到自定義獲取CLASS文件的目的。
首先我們看ClassLoader的核心方法loadClass
protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded，看緩存有沒(méi)有沒(méi)有才去找
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                //先看是不是最頂層，如果不是則parent為空，然后獲取父類
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    //如果為空則說(shuō)明應(yīng)用啟動(dòng)類加載器，讓它去加載
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }
            if (c == null) {
                // If still not found, then invoke findClass in order
                //如果還是沒(méi)有就調(diào)用自己的方法，確保調(diào)用自己方法前都使用了父類方法，如此遞歸三次到頂
                long t1 = System.nanoTime();
                c = findClass(name);
                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}
protected Class<?> findClass(String name) throws ClassNotFoundException {
    throw new ClassNotFoundException(name);
}
通過(guò)復(fù)寫(xiě)loadClass方法，我們甚至可以讀取一份加了密的文件，然后在內(nèi)存里面解密，這樣別人反編譯你的源碼也沒(méi)用，因?yàn)閏lass是經(jīng)過(guò)加密的，也就是理論上我們通過(guò)自定義類加載器可以做到為所欲為，但是有個(gè)重要的原則下文介紹類加載器設(shè)計(jì)模式會(huì)提到。
一下給出一個(gè)自定義類加載器極簡(jiǎn)的案例，來(lái)說(shuō)明自定義類加載器的實(shí)現(xiàn)。
package com.zooncool.example.theory.jvm;
import java.io.FileInputStream;
import static java.lang.System.out;

public class ClassIsolationPrinciple {
    public static void main(String[] args) {
        try {
            String className = "com.zooncool.example.theory.jvm.ClassIsolationPrinciple$Demo"; //定義要加載類的全限定名
            Class<?> class1 = Demo.class;  //第一個(gè)類又系統(tǒng)默認(rèn)類加載器加載
            //第二個(gè)類MyClassLoader為自定義類加載器，自定義的目的是覆蓋加載類的邏輯
            Class<?> class2 = new MyClassLoader("target/classes").loadClass(className);
            out.println("-----------------class name-----------------");
            out.println(class1.getName());
            out.println(class2.getName());
            out.println("-----------------classLoader name-----------------");
            out.println(class1.getClassLoader());
            out.println(class2.getClassLoader());
            Demo.example = 1;//這里修改的系統(tǒng)類加載器加載的那個(gè)類的對(duì)象，而自定義加載器加載進(jìn)去的類的對(duì)象保持不變，也即是同時(shí)存在內(nèi)存，但沒(méi)有修改example的值。
            out.println("-----------------field value-----------------");
            out.println(class1.getDeclaredField("example").get(null));
            out.println(class2.getDeclaredField("example").get(null));
        }  catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
    }

    public static class Demo {
        public static int example = 0;
    }

    public static class MyClassLoader extends ClassLoader{
        private String classPath;
        public MyClassLoader(String classPath) {
            this.classPath = classPath;
        }
        //自定義類加載器繼承了ClassLoader，稱為一個(gè)可以加載類的加載器，同時(shí)覆蓋了loadClass方法，實(shí)現(xiàn)自己的邏輯
        @Override
        public Class<?> loadClass(String name) throws ClassNotFoundException {
            if(!name.contains("java.lang")){//排除掉加載系統(tǒng)默認(rèn)需要加載的內(nèi)心類，因?yàn)樾╊愔荒苡帜J(rèn)類加載器去加載，第三方加載會(huì)拋異常，具體原因下文解釋
                byte[] data = new byte[0];
                try {
                    data = loadByte(name);
                } catch (Exception e) {
                    e.printStackTrace();
                }
                return defineClass(name,data,0,data.length);
            }else{
                return super.loadClass(name);
            }
        }
        //把影片的二進(jìn)制類文件讀入內(nèi)存字節(jié)流
        private byte[] loadByte(String name) throws Exception {
            name = name.replaceAll("\\.", "/");
            String dir = classPath + "/" + name + ".class";
            FileInputStream fis = new FileInputStream(dir);
            int len = fis.available();
            byte[] data = new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }
    }
}
執(zhí)行結(jié)果如下，我們可以看到加載到內(nèi)存方法區(qū)的兩個(gè)類的包名+名稱是一樣的，而對(duì)應(yīng)的類加載器卻不一樣，而且輸出被加載類的值也是不一樣的。
-----------------class name-----------------
com.zooncool.example.theory.jvm.ClassIsolationPrinciple2$Demo
com.zooncool.example.theory.jvm.ClassIsolationPrinciple2$Demo
-----------------classLoader name-----------------
sun.misc.Launcher$AppClassLoader@18b4aac2
com.zooncool.example.theory.jvm.ClassIsolationPrinciple2$MyClassLoader@511d50c0
-----------------field value-----------------
1
0
4.2.3設(shè)計(jì)模式

現(xiàn)有的加載器分為內(nèi)置類加載器和自定義加載器，不管它們是通過(guò)C或者JAVA實(shí)現(xiàn)的最終都是為了把外部的CLASS文件加載到JVM內(nèi)存里面。那么我們就需要設(shè)計(jì)一套規(guī)則來(lái)管理組織內(nèi)存里面的CLASS文件，下面我們就來(lái)介紹下通過(guò)這套規(guī)則如何來(lái)協(xié)調(diào)好內(nèi)置類加載器和自定義類加載器之間的權(quán)責(zé)。
我們知道通過(guò)自定義類加載器可以干出很多黑科技，但是有個(gè)基本的雷區(qū)就是，不能隨便替代JAVA的核心基礎(chǔ)類，或者說(shuō)即是你寫(xiě)了一個(gè)跟核心類一模一樣的類，JVM也不會(huì)使用。你想一下，如果為所欲為的你可以把最基礎(chǔ)本的java.lang.Object都換成你自己定義的同名類，然后搞個(gè)后門進(jìn)去，而且JVM還使用的話，那誰(shuí)還敢用JAVA了是吧，所以我們會(huì)介紹一個(gè)重要的原則，在此之前我們先介紹一下內(nèi)置類加載器和自定義類加載器是如何協(xié)同的。


(, 下載次數(shù): 7)

雙親委派機(jī)制很好理解，目的就是為了不重復(fù)加載已有的類，提高效率，還有就是強(qiáng)制從父類加載器開(kāi)始逐級(jí)搜索類文件，確保核心基礎(chǔ)類優(yōu)先加載。下面介紹的是破壞雙親委派機(jī)制，了解為什么要破壞這種看似穩(wěn)固的雙親委派機(jī)制。
介紹完內(nèi)置類加載器和自定義類加載器的協(xié)同關(guān)系后，我們要重點(diǎn)強(qiáng)調(diào)上文提到的重要原則。
4.2.4加載過(guò)程

至此我們已經(jīng)深刻認(rèn)識(shí)到類加載器的工作原理及其存在的意義，下面我們將介紹類從外部介質(zhì)加載使用到卸載整個(gè)閉環(huán)的生命周期。
加載

上文花了不少的篇幅說(shuō)明了類的結(jié)構(gòu)和類是如何被加載到JVM內(nèi)存里面的，那究竟什么時(shí)候JVM才會(huì)觸發(fā)類加載器去加載外部的CLASS文件呢？通常有如下四種情況會(huì)觸發(fā)到：
JVM只定了類加載器的規(guī)范，但卻不明確規(guī)定類加載器的目標(biāo)文件，把加載的具體邏輯充分交給了用戶，包括重硬盤加載的CLASS類到網(wǎng)絡(luò)，中間文件等，只要加載進(jìn)去內(nèi)存的二進(jìn)制數(shù)據(jù)流符合JVM規(guī)定的格式，都是合法的。
鏈接

類加載器加載完類到JVM實(shí)例的指定內(nèi)存區(qū)域(方法區(qū)下文會(huì)提到)后，是使用前會(huì)經(jīng)過(guò)驗(yàn)證，準(zhǔn)備解析的階段。
初始化

方法區(qū)經(jīng)過(guò)解析后類已經(jīng)為各個(gè)變量占好坑了，初始化就是把變量的初始值和構(gòu)造方法的內(nèi)容初始化到變量的空間里面。這時(shí)候我們介質(zhì)的類二進(jìn)制文件所定義的內(nèi)容，已經(jīng)完全被“翻譯”方法區(qū)的某一段內(nèi)存空間了。萬(wàn)事俱備只待使用了。
使用

使用呼應(yīng)了我們加載類的觸發(fā)條件，也即是觸發(fā)類加載的條件也是類應(yīng)用的條件，該操作會(huì)在初始化完成后進(jìn)行。
卸載

我們知道JVM有垃圾回收機(jī)制(下文會(huì)詳細(xì)介紹)，不需要我們操心，總體上有三個(gè)條件會(huì)觸發(fā)垃圾回收期清理方法區(qū)的空間：
本節(jié)結(jié)束我們已經(jīng)對(duì)整個(gè)類的生命周期爛熟于胸了，下面我們來(lái)介紹類加載機(jī)制最核心的幾種應(yīng)用場(chǎng)景，來(lái)加深對(duì)類加載技術(shù)的認(rèn)識(shí)。
4.3應(yīng)用場(chǎng)景

通過(guò)前文的剖析我們已經(jīng)非常清楚類加載器的工作原理，那么我們?cè)撊绾卫妙惣虞d器的特點(diǎn)，最大限度的發(fā)揮它的作用呢？
4.3.1熱部署

背景

熱部署這個(gè)詞匯我們經(jīng)常聽(tīng)說(shuō)也經(jīng)常提起，但是卻很少能夠準(zhǔn)確的描述出它的定義。說(shuō)到熱部署我們第一時(shí)間想到的可能是生產(chǎn)上的機(jī)器更新代碼后無(wú)需重啟應(yīng)用容器就能更新服務(wù)，這樣的好處就是服務(wù)無(wú)需中斷可持續(xù)運(yùn)行，那么與之對(duì)應(yīng)的冷部署當(dāng)然就是要重啟應(yīng)用容器實(shí)例了。還有可能會(huì)想到的是使用IDE工具開(kāi)發(fā)時(shí)不需要重啟服務(wù)，修改代碼后即時(shí)生效，這看起來(lái)可能都是服務(wù)無(wú)需重啟，但背后的運(yùn)行機(jī)制確截然不同，首先我們需要對(duì)熱部署下一個(gè)準(zhǔn)確的定義。
首先熱部署應(yīng)用容器擁有的一種能力，這種能力是容器本身設(shè)計(jì)出來(lái)的，跟具體的IDE開(kāi)發(fā)工具無(wú)關(guān)。而且熱部署無(wú)需重啟服務(wù)器，應(yīng)用可以保持用戶態(tài)不受影響。上文提到我們開(kāi)發(fā)環(huán)境使用IDE工具通常也可以設(shè)置無(wú)需重啟的功能，有別于熱部署的是此時(shí)我們應(yīng)用的是JVM的本身附帶的熱替換能力(HotSwap)。熱部署和熱替換是兩個(gè)完全不同概念，在開(kāi)發(fā)過(guò)程中也常常相互配合使用，導(dǎo)致我們很多人經(jīng)?；煜拍?，所以接下來(lái)我們來(lái)剖析熱部署的實(shí)現(xiàn)原理，而熱替換的高級(jí)特性我們會(huì)在下文字節(jié)碼增強(qiáng)的章節(jié)中介紹。
原理

從熱部署的定義我們知道它是應(yīng)用容器蘊(yùn)含的一項(xiàng)能力，要達(dá)到的目的就是在服務(wù)沒(méi)有重啟的情況下更新應(yīng)用，也就是把新的代碼編譯后產(chǎn)生的新類文件替換掉內(nèi)存里的舊類文件。結(jié)合前文我們介紹的類加載器特性，這似乎也不是很難，分兩步應(yīng)該可以完成。由于同一個(gè)類加載器只能加載一次類文件，那么新增一個(gè)類加載器把新的類文件加載進(jìn)內(nèi)存。此時(shí)內(nèi)存里面同時(shí)存在新舊的兩個(gè)類（類名路徑一樣，但是類加載器不一樣），要做的就是如何使用新的類，同時(shí)卸載舊的類及其對(duì)象，完成這兩步其實(shí)也就是熱部署的過(guò)程了。也即是通過(guò)使用新的類加載器，重新加載應(yīng)用的類，從而達(dá)到新代碼熱部署。
實(shí)現(xiàn)

理解了熱部署的工作原理，下面通過(guò)一系列極簡(jiǎn)的例子來(lái)一步步實(shí)現(xiàn)熱部署，為了方便讀者演示，以下例子我盡量都在一個(gè)java文件里面完成所有功能，運(yùn)行的時(shí)候復(fù)制下去就可以跑起來(lái)。
參考4.2.2中自定義類加載器區(qū)別系統(tǒng)默認(rèn)加載器的案例，從該案例實(shí)踐中我們可以將相同的類(包名+類名)，不同”版本“(類加載器不一樣)的類同時(shí)加載進(jìn)JVM內(nèi)存方法區(qū)。
既然一個(gè)類通過(guò)不同類加載器可以被多次加載到JVM內(nèi)存里面，那么類的經(jīng)過(guò)修改編譯后再加載進(jìn)內(nèi)存。有別于上一步給出的例子只是修改對(duì)象的值，這次我們是直接修改類的內(nèi)容，從應(yīng)用的視角看其實(shí)就是應(yīng)用更新，那如何做到在線程運(yùn)行不中斷的情況下更換新類呢？
下面給出的也是一個(gè)很簡(jiǎn)單的例子，ClassReloading啟動(dòng)main方法通過(guò)死循環(huán)不斷創(chuàng)建類加載器，同時(shí)不斷加載類而且執(zhí)行類的方法。注意new MyClassLoader(“target/classes”)的路徑更加編譯的class路徑來(lái)修改，其他直接復(fù)制過(guò)去就可以執(zhí)行演示了。
package com.zooncool.example.theory.jvm;
import java.io.FileInputStream;
import java.lang.reflect.InvocationTargetException;
public class ClassReloading {
    public static void main(String[] args)
        throws NoSuchMethodException, ClassNotFoundException, IllegalAccessException, InstantiationException,
        InvocationTargetException, InterruptedException {
        for (;;){//用死循環(huán)讓線程持續(xù)運(yùn)行未中斷狀態(tài)
            //通過(guò)反射調(diào)用目標(biāo)類的入口方法
            String className = "com.zooncool.example.theory.jvm.ClassReloading$User";
            Class<?> target = new MyClassLoader("target/classes").loadClass(className);
            //加載進(jìn)來(lái)的類，通過(guò)反射調(diào)用execute方法
            target.getDeclaredMethod("execute").invoke(targetClass.newInstance());
            //HelloWorld.class.getDeclaredMethod("execute").invoke(HelloWorld.class.newInstance());
            //如果換成系統(tǒng)默認(rèn)類加載器的話，因?yàn)殡p親委派原則，默認(rèn)使用應(yīng)用類加載器，而且能加載一次
            //休眠是為了在刪除舊類編譯新類的這段時(shí)間內(nèi)不執(zhí)行加載動(dòng)作
            //不然會(huì)找不到類文件
            Thread.sleep(10000);
        }
    }
    //自定義類加載器加載的目標(biāo)類
    public static class User {
        public void execute() throws InterruptedException {
            //say();
            ask();
        }
        public void ask(){
            System.out.println("what is your name");
        }
        public void say(){
            System.out.println("my name is lucy");
        }
    }
    //下面是自定義類加載器，跟第一個(gè)例子一樣，可略過(guò)
    public static class MyClassLoader extends ClassLoader{
        ...
    }
}
ClassReloading線程執(zhí)行過(guò)程不斷輪流注釋say()和ask()代碼，然后編譯類，觀察程序輸出。
如下輸出結(jié)果，我們可以看出每一次循環(huán)調(diào)用都新創(chuàng)建一個(gè)自定義類加載器，然后通過(guò)反射創(chuàng)建對(duì)象調(diào)用方法，在修改代碼編譯后，新的類就會(huì)通過(guò)反射創(chuàng)建對(duì)象執(zhí)行新的代碼業(yè)務(wù)，而主線程則一直沒(méi)有中斷運(yùn)行。讀到這里，其實(shí)我們已經(jīng)基本觸達(dá)了熱部署的本質(zhì)了，也就是實(shí)現(xiàn)了手動(dòng)無(wú)中斷部署。但是缺點(diǎn)就是需要我們手動(dòng)編譯代碼，而且內(nèi)存不斷新增類加載器和對(duì)象，如果速度過(guò)快而且頻繁更新，還可能造成堆溢出，下一個(gè)例子我們將增加一些機(jī)制來(lái)保證舊的類和對(duì)象能被垃圾收集器自動(dòng)回收。
what is your name
what is your name
what is your name//修改代碼，編譯新類
my name is lucy
my name is lucy
what is your name//修改代碼，編譯新類
通常情況下類加載器會(huì)持有該加載器加載過(guò)的所有類的引用，所有如果類是經(jīng)過(guò)系統(tǒng)默認(rèn)類加載器加載的話，那就很難被垃圾收集器回收，除非符合根節(jié)點(diǎn)不可達(dá)原則才會(huì)被回收。
下面繼續(xù)給出一個(gè)很簡(jiǎn)單的例子，我們知道ClassReloading只是不斷創(chuàng)建新的類加載器來(lái)加載新類從而更新類的方法。下面的例子我們模擬WEB應(yīng)用，更新整個(gè)應(yīng)用的上下文Context。下面代碼本質(zhì)上跟上個(gè)例子的功能是一樣的，只不過(guò)我們通過(guò)加載Model層、DAO層和Service層來(lái)模擬web應(yīng)用，顯得更加真實(shí)。
package com.zooncool.example.theory.jvm;
import java.io.FileInputStream;
import java.lang.reflect.InvocationTargetException;
//應(yīng)用上下文熱加載
public class ContextReloading {
    public static void main(String[] args)
        throws NoSuchMethodException, ClassNotFoundException, IllegalAccessException, InstantiationException,
        InvocationTargetException, InterruptedException {
        for (;;){
            Object context = newContext();//創(chuàng)建應(yīng)用上下文
            invokeContext(context);//通過(guò)上下文對(duì)象context調(diào)用業(yè)務(wù)方法
            Thread.sleep(5000);
        }
    }
    //創(chuàng)建應(yīng)用的上下文，context是整個(gè)應(yīng)用的GC roots，創(chuàng)建完返回對(duì)象之前調(diào)用init()初始化對(duì)象
    public static Object newContext()
        throws ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InstantiationException,
        InvocationTargetException {
        String className = "com.zooncool.example.theory.jvm.ContextReloading$Context";
        //通過(guò)自定義類加載器加載Context類
        Class<?> contextClass = new MyClassLoader("target/classes").loadClass(className);
        Object context = contextClass.newInstance();//通過(guò)反射創(chuàng)建對(duì)象
        contextClass.getDeclaredMethod("init").invoke(context);//通過(guò)反射調(diào)用初始化方法init()
        return context;
    }
    //業(yè)務(wù)方法，調(diào)用context的業(yè)務(wù)方法showUser()
    public static void invokeContext(Object context)
        throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
        context.getClass().getDeclaredMethod("showUser").invoke(context);
    }
    public static class Context{
        private UserService userService = new UserService();
        public String showUser(){
            return userService.getUserMessage();
        }
        //初始化對(duì)象
        public void init(){
            UserDao userDao = new UserDao();
            userDao.setUser(new User());
            userService.setUserDao(userDao);
        }
    }
    public static class UserService{
        private UserDao userDao;
        public String getUserMessage(){
            return userDao.getUserName();
        }
        public void setUserDao(UserDao userDao) {
            this.userDao = userDao;
        }
    }
    public static class UserDao{
        private User user;
        public String getUserName(){
            //關(guān)鍵操作，運(yùn)行main方法后切換下面方法，編譯后下一次調(diào)用生效
            return user.getName();
            //return user.getFullName();
        }
        public void setUser(User user) {
            this.user = user;
        }
    }

    public static class User{
        private String name = "lucy";
        private String fullName = "hank.lucy";
        public String getName() {
            System.out.println("my name is " + name);
            return name;
        }
        public String getFullName() {
            System.out.println("my full name is " + fullName);
            return name;
        }
    }
    //跟之前的類加載器一模一樣，可以略過(guò)
    public static class MyClassLoader extends ClassLoader{
        ...
    }
}
輸出結(jié)果跟上一個(gè)例子相似，可以自己運(yùn)行試試。我們更新業(yè)務(wù)方法編譯通過(guò)后，無(wú)需重啟main方法，新的業(yè)務(wù)就能生效，而且也解決了舊類卸載的核心問(wèn)題，因?yàn)閏ontext的應(yīng)用對(duì)象的跟節(jié)點(diǎn)，context是由我們自定義類加載器所加載，由于User/Dao/Service都是依賴context，所以其類也是又自定義類加載器所加載。根據(jù)GC roots原理，在創(chuàng)建新的自定義類加載器之后，舊的類加載器已經(jīng)沒(méi)有任何引用鏈可訪達(dá)，符合GC回收規(guī)則，將會(huì)被GC收集器回收釋放內(nèi)存。至此已經(jīng)完成應(yīng)用熱部署的流程，但是細(xì)心的朋友可能會(huì)發(fā)現(xiàn)，我們熱部署的策略是整個(gè)上下文context都替換成新的，那么用戶的狀態(tài)也將無(wú)法保留。而實(shí)際情況是我們只需要?jiǎng)討B(tài)更新某些模塊的功能，而不是全局。這個(gè)其實(shí)也好辦，就是我們從業(yè)務(wù)上把需要熱部署的由自定義類加載器加載，而持久化的類資源則由系統(tǒng)默認(rèn)類加載器去完成。
其實(shí)設(shè)計(jì)到代碼設(shè)計(jì)優(yōu)雅問(wèn)題，基本上我們拿出設(shè)計(jì)模式23章經(jīng)對(duì)號(hào)入座基本可以解決問(wèn)題，畢竟這是前人經(jīng)過(guò)千萬(wàn)實(shí)踐錘煉出來(lái)的軟件構(gòu)建內(nèi)功心法。那么針對(duì)我們熱部署的場(chǎng)景，如果想把熱部署細(xì)節(jié)封裝出來(lái)，那代理模式無(wú)疑是最符合要求的，也就是咱們弄出個(gè)代理對(duì)象來(lái)面向用戶，把類加載器的更替，回收，隔離等細(xì)節(jié)都放在代理對(duì)象里面完成，而對(duì)于用戶來(lái)說(shuō)是透明無(wú)感知的，那么終端用戶體驗(yàn)起來(lái)就是純粹的熱部署了。至于如何實(shí)現(xiàn)自動(dòng)熱部署，方式也很簡(jiǎn)單，監(jiān)聽(tīng)我們部署的目錄，如果文件時(shí)間和大小發(fā)生變化，則判斷應(yīng)用需要更新，這時(shí)候就觸發(fā)類加載器的創(chuàng)建和舊對(duì)象的回收，這個(gè)時(shí)候也可以引入觀察者模式來(lái)實(shí)現(xiàn)。由于篇幅限制，本例子就留給讀者朋友自行設(shè)計(jì)，相信也是不難完成的。
案例

上一節(jié)我們深入淺出的從自定義類加載器的開(kāi)始引入，到實(shí)現(xiàn)多個(gè)類加載器加載同個(gè)類文件，最后完成舊類加載器和對(duì)象的回收，整個(gè)流程闡述了熱部署的實(shí)現(xiàn)細(xì)節(jié)。那么這一節(jié)我們介紹現(xiàn)有實(shí)現(xiàn)熱部署的通用解決方案，本質(zhì)就是對(duì)上文原理的實(shí)現(xiàn)，加上性能和設(shè)計(jì)上的優(yōu)化，注意本節(jié)我們應(yīng)用的只是類加載器的技術(shù)，后面章節(jié)還會(huì)介紹的字節(jié)碼層面的底層操作技術(shù)。
OSGI(Open Service Gateway Initiative)是一套開(kāi)發(fā)和部署應(yīng)用程序的java框架。我們從官網(wǎng)可以看到OSGI其實(shí)是一套規(guī)范，好比Servlet定義了服務(wù)端對(duì)于處理來(lái)自網(wǎng)絡(luò)請(qǐng)求的一套規(guī)范，比如init，service，destroy的生命周期。然后我們通過(guò)實(shí)行這套規(guī)范來(lái)實(shí)現(xiàn)與客戶端的交互，在調(diào)用init初始化完Servlet對(duì)象后通過(guò)多線程模式使用service響應(yīng)網(wǎng)絡(luò)請(qǐng)求。如果從響應(yīng)模式比較我們還可以了解下Webflux的規(guī)范，以上兩種都是處理網(wǎng)絡(luò)請(qǐng)求的方式，當(dāng)然你舉例說(shuō)CGI也是一種處理網(wǎng)絡(luò)請(qǐng)求的規(guī)范，CGI采用的是多進(jìn)程方式來(lái)處理網(wǎng)絡(luò)請(qǐng)求，我們暫時(shí)不對(duì)這兩種規(guī)范進(jìn)行優(yōu)劣評(píng)價(jià)，只是說(shuō)明在處理網(wǎng)絡(luò)請(qǐng)求的場(chǎng)景下可以采用不同的規(guī)范來(lái)實(shí)現(xiàn)。
好了現(xiàn)在回到OSGi，有了上面的鋪墊，相信對(duì)我們理解OSGI大有幫助。我們說(shuō)OSGI首先是一種規(guī)范，既然是規(guī)范我們就要看看都規(guī)范了啥，比如Servlet也是一種規(guī)范，它規(guī)范了生命周期，規(guī)定應(yīng)用容器中WEB-INF/classes目錄或WEB-INF/lib目錄下的jar包才會(huì)被Web容器處理。同樣OSGI的實(shí)現(xiàn)框架對(duì)管轄的Bundle下面的目錄組織和文本格式也有嚴(yán)格規(guī)范，更重要的是OSGI對(duì)模塊化架構(gòu)生命周期的管理。而模塊化也不只是把系統(tǒng)拆分成不同的JAR包形成模塊而已，真正的模塊化必須將模塊中類的引入/導(dǎo)出、隱藏、依賴、版本管理貫穿到生命周期管理中去。
定義：OSGI是脫胎于(OSGI Alliance)技術(shù)聯(lián)盟由一組規(guī)范和對(duì)應(yīng)子規(guī)范共同定義的JAVA動(dòng)態(tài)模塊化技術(shù)。實(shí)現(xiàn)該規(guī)范的OSGI框架(如Apache Felix)使應(yīng)用程序的模塊能夠在本地或者網(wǎng)絡(luò)中實(shí)現(xiàn)端到端的通信，目前已經(jīng)發(fā)布了第7版。OSGI有很多優(yōu)點(diǎn)諸如熱部署，類隔離，高內(nèi)聚，低耦合的優(yōu)勢(shì)，但同時(shí)也帶來(lái)了性能損耗，而且基于OSGI目前的規(guī)范繁多復(fù)雜，開(kāi)發(fā)門檻較高。
組成：執(zhí)行環(huán)境，安全層，模塊層，生命周期層，服務(wù)層，框架API
核心服務(wù)：
事件服務(wù)（Event Admin Service），
包管理服務(wù)（Package Admin Service）
日志服務(wù)（Log Service）
配置管理服務(wù)（Configuration Admin Service）
HTTP服務(wù)（HTTP Service）
用戶管理服務(wù)（User Admin Service）
設(shè)備訪問(wèn)服務(wù)（Device Access Service）
IO連接器服務(wù)（IO Connector Service）
聲明式服務(wù)（Declarative Services）
其他OSGi標(biāo)準(zhǔn)服務(wù)

(, 下載次數(shù): 6)

本節(jié)我們討論的核心是熱部署，所以我們不打算在這里講解全部得OSGI技術(shù)，在上文實(shí)現(xiàn)熱部署后我們重點(diǎn)來(lái)剖析OSGI關(guān)于熱部署的機(jī)制。至于OSGI模塊化技術(shù)和java9的模塊化的對(duì)比和關(guān)聯(lián)，后面有時(shí)間會(huì)開(kāi)個(gè)專題專門介紹模塊化技術(shù)。
從類加載器技術(shù)應(yīng)用的角度切入我們知道OSGI規(guī)范也是打破雙親委派機(jī)制，除了框架層面需要依賴JVM默認(rèn)類加載器之外，其他Bundle(OSGI定義的模塊單元)都是由各自的類加載器來(lái)加載，而OSGI框架就負(fù)責(zé)模塊生命周期，模塊交互這些核心功能，同時(shí)創(chuàng)建各個(gè)Bundle的類加載器，用于直接加載Bundle定義的jar包。由于打破雙親委派模式，Bundle類加載器不再是雙親委派模型中的樹(shù)狀結(jié)構(gòu)，而是進(jìn)一步發(fā)展為更加復(fù)雜的網(wǎng)狀結(jié)構(gòu)(因?yàn)楦鱾€(gè)Bundle之間有相互依賴關(guān)系)，當(dāng)收到類加載請(qǐng)求時(shí)，OSGi將按照下面的順序進(jìn)行類搜索：
1）將以java.*開(kāi)頭的類委派給父類加載器加載。
2）否則，將委派列表名單內(nèi)(比如sun或者javax這類核心類的包加入白名單)的類委派給父類加載器加載。
3）否則，將Import列表中的類委派給Export這個(gè)類的Bundle的類加載器加載。
4）否則，查找當(dāng)前Bundle的ClassPath，使用自己的類加載器加載。
5）否則，查找類是否在自己的Fragment Bundle(OSGI框架緩存包)中，如果在，則委派給Fragment Bundle的類加載器加載。
6）否則，查找Dynamic Import列表的Bundle，委派給對(duì)應(yīng)Bundle的類加載器加載。
7）否則，類查找失敗。
這一系列的類加載操作，其實(shí)跟我們上節(jié)實(shí)現(xiàn)的自定義類加載技術(shù)本質(zhì)上是一樣的，只不過(guò)實(shí)現(xiàn)OSGI規(guī)范的框架需要提供模塊之間的注冊(cè)通信組件，還有模塊的生命周期管理，版本管理。OSGI也只是JVM上面運(yùn)行的一個(gè)普通應(yīng)用實(shí)例，只不過(guò)通過(guò)模塊內(nèi)聚，版本管理，服務(wù)依賴一系列的管理，實(shí)現(xiàn)了模塊的即時(shí)更新，實(shí)現(xiàn)了熱部署。
其他熱部署解決方案多數(shù)也是利用類加載器的特點(diǎn)做文章，當(dāng)然不止是類加載器，還會(huì)應(yīng)用字節(jié)碼技術(shù)，下面我們主要簡(jiǎn)單列舉應(yīng)用類加載器實(shí)現(xiàn)的熱部署解決方案。
Groovy兼顧動(dòng)態(tài)腳本語(yǔ)言的功能，使用的時(shí)候無(wú)外乎也是通過(guò)GroovyClassLoader來(lái)加載腳本文件，轉(zhuǎn)為JVM的類對(duì)象。那么每次更新groovy腳本就可以動(dòng)態(tài)更新應(yīng)用，也就達(dá)到了熱部署的功能了。
Class groovyClass = classLoader.parseClass(new GroovyCodeSource(sourceFile));
GroovyObject instance = (GroovyObject)groovyClass.newInstance();//proxy
介紹完熱部署技術(shù)，可能很多同學(xué)對(duì)熱部署的需求已經(jīng)沒(méi)有那么強(qiáng)烈，畢竟熱部署過(guò)程中帶來(lái)的弊端也不容忽視，比如替換舊的類加載器過(guò)程會(huì)產(chǎn)生大量的內(nèi)存碎片，導(dǎo)致JVM進(jìn)行高負(fù)荷的GC工作，反復(fù)進(jìn)行熱部署還會(huì)導(dǎo)致JVM內(nèi)存不足而導(dǎo)致內(nèi)存溢出，有時(shí)候甚至還不如直接重啟應(yīng)用來(lái)得更快一點(diǎn)，而且隨著分布式架構(gòu)的演進(jìn)和微服務(wù)的流行，應(yīng)用重啟也早就實(shí)現(xiàn)服務(wù)編排化，配合豐富的部署策略，也可以同樣保證系統(tǒng)穩(wěn)定持續(xù)服務(wù)，我們更多的是通過(guò)熱部署技術(shù)來(lái)深刻認(rèn)識(shí)到JVM加載類的技術(shù)演進(jìn)。
4.3.2類隔離

背景

先介紹一下類隔離的背景，我們費(fèi)了那么大的勁設(shè)計(jì)出類加載器，如果只是用于加載外部類字節(jié)流那就過(guò)于浪費(fèi)了。通常我們的應(yīng)用依賴不同的第三方類庫(kù)經(jīng)常會(huì)出現(xiàn)不同版本的類庫(kù)，如果只是使用系統(tǒng)內(nèi)置的類加載器的話，那么一個(gè)類庫(kù)只能加載唯一的一個(gè)版本，想加載其他版本的時(shí)候會(huì)從緩存里面發(fā)現(xiàn)已經(jīng)存在而停止加載。但是我們的不同業(yè)務(wù)以來(lái)的往往是不同版本的類庫(kù)，這時(shí)候就會(huì)出現(xiàn)ClassNotFoundException。為什么只有運(yùn)行的是才會(huì)出現(xiàn)這個(gè)異常呢，因?yàn)榫幾g的時(shí)候我們通常會(huì)使用MAVEN等編譯工具把沖突的版本排除掉。另外一種情況是WEB容器的內(nèi)核依賴的第三方類庫(kù)需要跟應(yīng)用依賴的第三方類庫(kù)隔離開(kāi)來(lái)，避免一些安全隱患，不然如果共用的話，應(yīng)用升級(jí)依賴版本就會(huì)導(dǎo)致WEB容器不穩(wěn)定。
基于以上的介紹我們知道類隔離實(shí)在是剛需，那么接下來(lái)介紹一下如何實(shí)現(xiàn)這個(gè)剛需。
原理

首先我們要了解一下原理，其實(shí)原理很簡(jiǎn)單，真的很簡(jiǎn)單，請(qǐng)?jiān)试S我總結(jié)為“唯一標(biāo)識(shí)原理”。我們知道內(nèi)存里面定位類實(shí)例的坐標(biāo)<類加載器,類全限定名>。那么由這兩個(gè)因子組合起來(lái)我們可以得出一種普遍的應(yīng)用，用不同類加載器來(lái)加載類相同類(類全限定名一致，版本不一致)是可以實(shí)現(xiàn)的，也就是在JVM看來(lái)，有相同類全名的類是完全不同的兩個(gè)實(shí)例，但是在業(yè)務(wù)視角我們卻可以視為相同的類。
public static void main(String[] args) {
   Class<?> userClass1 = User.class;
   Class<?> userClass2 = new DynamicClassLoader("target/classes")
         .load("qj.blog.classreloading.example1.StaticInt$User");

   out.println("Seems to be the same class:");
   out.println(userClass1.getName());
   out.println(userClass2.getName());
   out.println();

   out.println("But why there are 2 different class loaders:");
   out.println(userClass1.getClassLoader());
   out.println(userClass2.getClassLoader());
   out.println();

   User.age = 11;
   out.println("And different age values:");
   out.println((int) ReflectUtil.getStaticFieldValue("age", userClass1));
   out.println((int) ReflectUtil.getStaticFieldValue("age", userClass2));
}

public static class User {
   public static int age = 10;
}
實(shí)現(xiàn)

原理很簡(jiǎn)單，比如我們知道Spring容器本質(zhì)就是一個(gè)生產(chǎn)和管理bean的集合對(duì)象，但是卻包含了大量的優(yōu)秀設(shè)計(jì)模式和復(fù)雜的框架實(shí)現(xiàn)。同理隔離容器雖然原理很簡(jiǎn)單，但是要實(shí)現(xiàn)一個(gè)高性能可擴(kuò)展的高可用隔離容器，卻不是那么簡(jiǎn)單。我們上文談的場(chǎng)景是在內(nèi)存運(yùn)行的時(shí)候才發(fā)現(xiàn)問(wèn)題，介紹內(nèi)存隔離技術(shù)之前，我們先普及更為通用的沖突解決方法。
5.內(nèi)存管理

5.1內(nèi)存結(jié)構(gòu)

5.1.1邏輯分區(qū)

JVM內(nèi)存從應(yīng)用邏輯上可分為如下區(qū)域。
而實(shí)際上JVM內(nèi)存分類實(shí)際上的物理分區(qū)還有更為詳細(xì)，整體上分為堆內(nèi)存和非堆內(nèi)存，具體介紹如下。
5.1.2 內(nèi)存模型

堆內(nèi)存

堆內(nèi)存是運(yùn)行時(shí)的數(shù)據(jù)區(qū)，從中分配所有java類實(shí)例和數(shù)組的內(nèi)存，可以理解為目標(biāo)應(yīng)用依賴的對(duì)象。堆在JVM啟動(dòng)時(shí)創(chuàng)建，并且在應(yīng)用程序運(yùn)行時(shí)可能會(huì)增大或減小?？梢允褂?Xms 選項(xiàng)指定堆的大小。堆可以是固定大小或可變大小，具體取決于垃圾收集策略?？梢允褂?Xmx選項(xiàng)設(shè)置最大堆大小。默認(rèn)情況下，最大堆大小設(shè)置為64 MB。
JVM堆內(nèi)存在物理上分為兩部分：新生代和老年代。新生代是為分配新對(duì)象而保留堆空間。當(dāng)新生代占用完時(shí)，Minor GC垃圾收集器會(huì)對(duì)新生代區(qū)域執(zhí)行垃圾回收動(dòng)作，其中在新生代中生活了足夠長(zhǎng)的所有對(duì)象被遷移到老年代，從而釋放新生代空間以進(jìn)行更多的對(duì)象分配。此垃圾收集稱為 Minor GC。新生代分為三個(gè)子區(qū)域：伊甸園Eden區(qū)和兩個(gè)幸存區(qū)S0和S1。

(, 下載次數(shù): 7)

關(guān)于新生代內(nèi)存空間：
當(dāng)老年區(qū)填滿時(shí)，老年區(qū)同樣會(huì)執(zhí)行垃圾回收，老年區(qū)還包含那些經(jīng)過(guò)多Minor GC后還存活的長(zhǎng)壽對(duì)象。垃圾收集器在老年代內(nèi)存中執(zhí)行的回收稱為Major GC，通常需要更長(zhǎng)的時(shí)間。
非堆內(nèi)存

JVM的堆以外內(nèi)存稱為非堆內(nèi)存。也即是JVM自身預(yù)留的內(nèi)存區(qū)域，包含JVM緩存空間，類結(jié)構(gòu)如常量池、字段和方法數(shù)據(jù)，方法，構(gòu)造方法。類非堆內(nèi)存的默認(rèn)最大大小為64 MB?？梢允褂?XX：MaxPermSize VM選項(xiàng)更改此選項(xiàng)，非堆內(nèi)存通常包含如下性質(zhì)的區(qū)域空間：
在Java 8以上版本已經(jīng)沒(méi)有Perm Gen這塊區(qū)域了，這也意味著不會(huì)再由關(guān)于“java.lang.OutOfMemoryError：PermGen”內(nèi)存問(wèn)題存在了。與駐留在Java堆中的Perm Gen不同，Metaspace不是堆的一部分。類元數(shù)據(jù)多數(shù)情況下都是從本地內(nèi)存中分配的。默認(rèn)情況下，元空間會(huì)自動(dòng)增加其大小(直接又底層操作系統(tǒng)提供)，而Perm Gen始終具有固定的上限?？梢允褂脙蓚€(gè)新標(biāo)志來(lái)設(shè)置Metaspace的大小，它們是：“ - XX：MetaspaceSize ”和“ -XX：MaxMetaspaceSize ”。Metaspace背后的含義是類的生命周期及其元數(shù)據(jù)與類加載器的生命周期相匹配。也就是說(shuō)，只要類加載器處于活動(dòng)狀態(tài)，元數(shù)據(jù)就會(huì)在元數(shù)據(jù)空間中保持活動(dòng)狀態(tài)，并且無(wú)法釋放。
運(yùn)行Java程序時(shí)，它以分層方式執(zhí)行代碼。在第一層，它使用客戶端編譯器（C1編譯器）來(lái)編譯代碼。分析數(shù)據(jù)用于服務(wù)器編譯的第二層（C2編譯器），以優(yōu)化的方式編譯該代碼。默認(rèn)情況下，Java 7中未啟用分層編譯，但在Java 8中啟用了分層編譯。實(shí)時(shí)（JIT）編譯器將編譯的代碼存儲(chǔ)在稱為代碼緩存的區(qū)域中。它是一個(gè)保存已編譯代碼的特殊堆。如果該區(qū)域的大小超過(guò)閾值，則該區(qū)域?qū)⒈凰⑿?，并且GC不會(huì)重新定位這些對(duì)象。Java 8中已經(jīng)解決了一些性能問(wèn)題和編譯器未重新啟用的問(wèn)題，并且在Java 7中避免這些問(wèn)題的解決方案之一是將代碼緩存的大小增加到一個(gè)永遠(yuǎn)不會(huì)達(dá)到的程度。
方法區(qū)域是Perm Gen中空間的一部分，用于存儲(chǔ)類結(jié)構(gòu)（運(yùn)行時(shí)常量和靜態(tài)變量）以及方法和構(gòu)造函數(shù)的代碼。
內(nèi)存池由JVM內(nèi)存管理器創(chuàng)建，用于創(chuàng)建不可變對(duì)象池。內(nèi)存池可以屬于Heap或Perm Gen，具體取決于JVM內(nèi)存管理器實(shí)現(xiàn)。
常量包含類運(yùn)行時(shí)常量和靜態(tài)方法，常量池是方法區(qū)域的一部分。
Java堆棧內(nèi)存用于執(zhí)行線程。它們包含特定于方法的特定值，以及對(duì)從該方法引用的堆中其他對(duì)象的引用。
Java提供了許多內(nèi)存配置項(xiàng)，我們可以使用它們來(lái)設(shè)置內(nèi)存大小及其比例，常用的如下：
VM Switch描述
- Xms用于在JVM啟動(dòng)時(shí)設(shè)置初始堆大小
-Xmx用于設(shè)置最大堆大小
-Xmn設(shè)置新生區(qū)的大小，剩下的空間用于老年區(qū)
-XX：PermGen用于設(shè)置永久區(qū)存初始大小
-XX：MaxPermGen用于設(shè)置Perm Gen的最大尺寸
-XX：SurvivorRatio提供Eden區(qū)域的比例
-XX：NewRatio用于提供老年代/新生代大小的比例，默認(rèn)值為2
5.2垃圾回收

5.2.1垃圾回收策略

流程

垃圾收集是釋放堆中的空間以分配新對(duì)象的過(guò)程。垃圾收集器是JVM管理的進(jìn)程，它可以查看內(nèi)存中的所有對(duì)象，并找出程序任何部分未引用的對(duì)象，刪除并回收空間以分配給其他對(duì)象。通常會(huì)經(jīng)過(guò)如下步驟：
策略

虛擬機(jī)棧、本地棧和程序計(jì)數(shù)器在編譯完畢后已經(jīng)可以確定所需內(nèi)存空間，程序執(zhí)行完畢后也會(huì)自動(dòng)釋放所有內(nèi)存空間，所以不需要進(jìn)行動(dòng)態(tài)回收優(yōu)化。JVM內(nèi)存調(diào)優(yōu)主要針對(duì)堆和方法區(qū)兩大區(qū)域的內(nèi)存。通常對(duì)象分為Strong、sfot、weak和phantom四種類型，強(qiáng)引用不會(huì)被回收，軟引用在內(nèi)存達(dá)到溢出邊界時(shí)回收，弱引用在每次回收周期時(shí)回收，虛引用專門被標(biāo)記為回收對(duì)象，具體回收策略如下：
算法

垃圾收集有如下常用的算法：
5.2.2 垃圾回收器

分類

配置

6.執(zhí)行引擎

6.1執(zhí)行流程

類加載器加載的類文件字節(jié)碼數(shù)據(jù)流由基于JVM指令集架構(gòu)的執(zhí)行引擎來(lái)執(zhí)行。執(zhí)行引擎以指令為單位讀取Java字節(jié)碼。我們知道匯編執(zhí)行的流程是CPU執(zhí)行每一行的匯編指令，同樣JVM執(zhí)行引擎就像CPU一個(gè)接一個(gè)地執(zhí)行機(jī)器命令。字節(jié)碼的每個(gè)命令都包含一個(gè)1字節(jié)的OpCode和附加的操作數(shù)。執(zhí)行引擎獲取一個(gè)OpCode并使用操作數(shù)執(zhí)行任務(wù)，然后執(zhí)行下一個(gè)OpCode。但Java是用人們可以理解的語(yǔ)言編寫(xiě)的，而不是用機(jī)器直接執(zhí)行的語(yǔ)言編寫(xiě)的。因此執(zhí)行引擎必須將字節(jié)碼更改為JVM中的機(jī)器可以執(zhí)行的語(yǔ)言。字節(jié)碼可以通過(guò)以下兩種方式之一轉(zhuǎn)化為合適的語(yǔ)言。
但是，JIT編譯器編譯代碼需要花費(fèi)更多的時(shí)間，而不是解釋器逐個(gè)解釋代碼。因此，如果代碼只執(zhí)行一次，最好是選擇解釋而不是編譯。因此，使用JIT編譯器的JVM在內(nèi)部檢查方法執(zhí)行的頻率，并僅在頻率高于某個(gè)級(jí)別時(shí)編譯方法。

(, 下載次數(shù): 7)

JVM規(guī)范中未定義執(zhí)行引擎的運(yùn)行方式。因此，JVM廠商使用各種技術(shù)改進(jìn)其執(zhí)行引擎，并引入各種類型的JIT編譯器。 大多數(shù)JIT編譯器運(yùn)行如下圖所示：

(, 下載次數(shù): 7)

JIT編譯器將字節(jié)碼轉(zhuǎn)換為中間級(jí)表達(dá)式IR，以執(zhí)行優(yōu)化，然后將表達(dá)式轉(zhuǎn)換為本機(jī)代碼。Oracle Hotspot VM使用名為Hotspot Compiler的JIT編譯器。它被稱為Hotspot，因?yàn)镠otspot Compiler通過(guò)分析搜索需要以最高優(yōu)先級(jí)進(jìn)行編譯的“Hotspot”，然后將熱點(diǎn)編譯為本機(jī)代碼。如果不再頻繁調(diào)用編譯了字節(jié)碼的方法，換句話說(shuō)，如果該方法不再是熱點(diǎn)，則Hotspot VM將從緩存中刪除本機(jī)代碼并以解釋器模式運(yùn)行。Hotspot VM分為服務(wù)器VM和客戶端VM，兩個(gè)VM使用不同的JIT編譯器。
大多數(shù)Java性能改進(jìn)都是通過(guò)改進(jìn)執(zhí)行引擎來(lái)實(shí)現(xiàn)的。除了JIT編譯器之外，還引入了各種優(yōu)化技術(shù)，因此可以不斷改進(jìn)JVM性能。初始JVM和最新JVM之間的最大區(qū)別是執(zhí)行引擎。
下面我們通過(guò)下圖可以看出JAVA執(zhí)行的流程。

(, 下載次數(shù): 8)

6.2棧幀結(jié)構(gòu)

每個(gè)方法調(diào)用開(kāi)始到執(zhí)行完成的過(guò)程，對(duì)應(yīng)這一個(gè)棧幀在虛擬機(jī)棧里面從入棧到出棧的過(guò)程。
下圖是JVM實(shí)例執(zhí)行方法是的內(nèi)存布局。

(, 下載次數(shù): 6)

6.3早期編譯

6.4晚期編譯

HotSpot虛擬機(jī)內(nèi)的即時(shí)編譯
解析模式 -Xint
編譯模式 -Xcomp
混合模式 Mixed mode
分層編譯：解釋執(zhí)行 -> C1(Client Compiler)編譯 -> C2編譯(Server Compiler)
觸發(fā)條件：基于采樣的熱點(diǎn)探測(cè)，基于計(jì)數(shù)器的熱點(diǎn)探測(cè)
7.性能調(diào)優(yōu)

7.1調(diào)優(yōu)原則

我們知道調(diào)優(yōu)的前提是，程序沒(méi)有達(dá)到我們的預(yù)期要求，那么第一步要做的是衡量我們的預(yù)期。程序不可能十全十美，我們要做的是通過(guò)各種指標(biāo)來(lái)衡量系統(tǒng)的性能，最終整體達(dá)到我們的要求。
7.1.1 環(huán)境

首先我們要了解系統(tǒng)的運(yùn)行環(huán)境，包括操作系統(tǒng)層面的差異，JVM版本，位數(shù)，乃至于硬件的時(shí)鐘周期，總線設(shè)計(jì)甚至機(jī)房溫度，都可能是我們需要考慮的前置條件。
7.1.2 度量

首先我們要先給出系統(tǒng)的預(yù)期指標(biāo)，在特定的硬件/軟件的配置，然后給出目標(biāo)指標(biāo)，比如系統(tǒng)整體輸出接口的QPS,RT，或者更進(jìn)一層，IO讀寫(xiě)，cpu的load指標(biāo)，內(nèi)存的使用率，GC情況都是我們需要預(yù)先考察的對(duì)象。
7.1.3 監(jiān)測(cè)

確定了環(huán)境前置條件，分析了度量指標(biāo)，第三步是通過(guò)工具來(lái)監(jiān)測(cè)指標(biāo)，下一節(jié)提供了常用JVM調(diào)優(yōu)工具，可以通過(guò)不同工具的組合來(lái)發(fā)現(xiàn)定位問(wèn)題，結(jié)合JVM的工作機(jī)制已經(jīng)操作系統(tǒng)層面的調(diào)度流程，按圖索驥來(lái)發(fā)現(xiàn)問(wèn)題，找出問(wèn)題后才能進(jìn)行優(yōu)化。
7.1.4 原則

總體的調(diào)優(yōu)原則如下圖

(, 下載次數(shù): 6)

圖片來(lái)源《Java Performance》
7.2 調(diào)優(yōu)參數(shù)

上節(jié)給出了JVM性能調(diào)優(yōu)的原則，我們理清思路后應(yīng)用不同的JVM工具來(lái)發(fā)現(xiàn)系統(tǒng)存在的問(wèn)題，下面列舉的是常用的JVM參數(shù)，通過(guò)這些參數(shù)指標(biāo)可以更快的幫助我們定位出問(wèn)題所在。
7.2.1內(nèi)存查詢

最常見(jiàn)的與性能相關(guān)的做法之一是根據(jù)應(yīng)用程序要求初始化堆內(nèi)存。這就是我們應(yīng)該指定最小和最大堆大小的原因。以下參數(shù)可用于實(shí)現(xiàn)它：
-Xms<heap size>[unit] -Xmx<heap size>[unit]
unit表示要初始化內(nèi)存（由堆大小表示）的單元。單位可以標(biāo)記為GB的“g”，MB的“m”和KB的“k”。例如JVM分配最小2 GB和最大5 GB：
-Xms2G -Xmx5G
從Java 8開(kāi)始Metaspace的大小未被定義，一旦達(dá)到限制JVM會(huì)自動(dòng)增加它，為了避免不必要的不穩(wěn)定性，我們可以設(shè)置Metaspace大?。?br /> -XX:MaxMetaspaceSize=<metaspace size>[unit]
默認(rèn)情況下YG的最小大小為1310 MB，最大大小不受限制，我們可以明確地指定它們：
-XX:NewSize=<young size>[unit]
-XX:MaxNewSize=<young size>[unit]
7.2.2垃圾回收

JVM有四種類型的GC實(shí)現(xiàn)：
可以使用以下參數(shù)聲明這些實(shí)現(xiàn)：
-XX:+UseSerialGC
-XX:+UseParallelGC
-XX:+USeParNewGC
-XX:+UseG1GC
7.2.3GC記錄

要嚴(yán)格監(jiān)視應(yīng)用程序運(yùn)行狀況，我們應(yīng)始終檢查JVM的垃圾收集性能，使用以下參數(shù)，我們可以記錄GC活動(dòng)：
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=< number of log files >
-XX:GCLogFileSize=< file size >[ unit ]
-Xloggc:/path/to/gc.log
UseGCLogFileRotation指定日志文件滾動(dòng)的政策，就像log4j的，s4lj等 NumberOfGCLogFiles表示單個(gè)應(yīng)用程序記錄生命周期日志文件的最大數(shù)量。GCLogFileSize指定文件的最大大小。 loggc表示其位置。這里要注意的是，還有兩個(gè)可用的JVM參數(shù)（-XX：+ PrintGCTimeStamps和-XX：+ PrintGCDateStamps），可用于在GC日志中打印日期時(shí)間戳。
7.2.4內(nèi)存溢出

大型應(yīng)用程序面臨內(nèi)存不足的錯(cuò)誤是很常見(jiàn)的，這是一個(gè)非常關(guān)鍵的場(chǎng)景，很難復(fù)制以解決問(wèn)題。
這就是JVM帶有一些參數(shù)的原因，這些參數(shù)將堆內(nèi)存轉(zhuǎn)儲(chǔ)到一個(gè)物理文件中，以后可以用它來(lái)查找泄漏：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./java_pid<pid>.hprof
-XX:OnOutOfMemoryError="< cmd args >;< cmd args >"
-XX:+UseGCOverheadLimit
這里有幾點(diǎn)需要注意：
-XX:OnOutOfMemoryError="shutdown -r"
7.2.5其他配置

7.3 調(diào)優(yōu)工具

7.3.1命令行工具

7.3.2可視化工具

8.字節(jié)增強(qiáng)

我們從類加載的應(yīng)用介紹了熱部署和類隔離兩大應(yīng)用場(chǎng)景，但是基于類加載器的技術(shù)始終只是獨(dú)立于JVM內(nèi)核功能而存在的，也就是所有實(shí)現(xiàn)都只是基于最基礎(chǔ)的類加載機(jī)制，并無(wú)應(yīng)用其他JVM 高級(jí)特性，本章節(jié)我們開(kāi)始從字節(jié)增強(qiáng)的層面介紹JVM的一些高級(jí)特性。
說(shuō)到字節(jié)增強(qiáng)我們最先想到的是字節(jié)碼，也就是本文最開(kāi)頭所要研究的class文件，任何合法的源碼編譯成class后被類加載器加載進(jìn)JVM的方法區(qū)，也就是以字節(jié)碼的形態(tài)存活在JVM的內(nèi)存空間。這也就是我們?yōu)槭裁船F(xiàn)有講明白類的結(jié)構(gòu)和加載過(guò)程，而字節(jié)碼增強(qiáng)技術(shù)不只是在內(nèi)存里面對(duì)class的字節(jié)碼進(jìn)行操縱，更為復(fù)雜的是class聯(lián)動(dòng)的上下游對(duì)象生命周期的管理。
首先我們回憶一下我們開(kāi)發(fā)過(guò)程中最為熟悉的一個(gè)場(chǎng)景就是本地debug調(diào)試代碼?？赡芎芏嗤瑢W(xué)都已經(jīng)習(xí)慣在IDE上對(duì)某句代碼打上斷點(diǎn)，然后逐步往下追蹤代碼執(zhí)行的步驟。我們進(jìn)一步想想，這個(gè)是怎么實(shí)現(xiàn)的，是一股什么樣的力量能把已經(jīng)跑起來(lái)的線程踩下剎車，一步一步往前挪？我們知道線程運(yùn)行其實(shí)就是在JVM的?？臻g上不斷的把代碼對(duì)應(yīng)的JVM指令集不斷的送到CPU執(zhí)行。那能阻止這個(gè)流程的力量也肯定是發(fā)生在JVM范圍內(nèi)，所以我們可以很輕松的預(yù)測(cè)到這肯定是JVM提供的機(jī)制，而不是IDE真的有這樣的能力，只不過(guò)是JVM把這種能力封裝成接口暴露出去，然后提供給IDE調(diào)用，而IDE只不過(guò)是通過(guò)界面交互來(lái)調(diào)用這些接口而已。那么下面我們就來(lái)介紹JVM這種重要的能力。
8.1JPDA

上面所講的JVM提供的程序運(yùn)行斷點(diǎn)能力，其實(shí)JVM提供的一個(gè)工具箱JVMTI(JVM TOOL Interface)提供的接口，而這個(gè)工具箱是一套叫做JPDA的架構(gòu)定義的，本節(jié)我們就來(lái)聊聊JPDA。
JPDA(Java Platform Debugger Architecture)Java平臺(tái)調(diào)試架構(gòu)，既不是一個(gè)應(yīng)用程序，也不是調(diào)試工具，而是定義了一系列設(shè)計(jì)良好的接口和協(xié)議用于調(diào)試java代碼，我們將會(huì)從三個(gè)層面來(lái)講解JPDA。
8.1.1概念



(, 下載次數(shù): 7)

8.1.2原理

介紹完JPDA的架構(gòu)體系后，我們了解到JAVA調(diào)試平臺(tái)各個(gè)層級(jí)的作用，這一節(jié)我們更近一步講解JPDA各個(gè)層面的工作原理，以及三個(gè)層級(jí)結(jié)合起來(lái)時(shí)如何交互的。
JVMTI

我們JVMTI是JVM提供的一套本地接口，包含了非常豐富的功能，我們調(diào)試和優(yōu)化代碼需要操作JVM，多數(shù)情況下就是調(diào)用到JVMTI，從官網(wǎng)我們可以看到，JVMTI包含了對(duì)JVM線程/內(nèi)存/堆/棧/類/方法/變量/事件/定時(shí)器處理等的20多項(xiàng)功能。但其實(shí)我們通常不是直接調(diào)用JVMTI，而是創(chuàng)建一個(gè)代理客戶端，我們可以自由的定義對(duì)JVMTI的操作然后打包到代理客戶端里面如libagent.so。當(dāng)目標(biāo)程序執(zhí)行時(shí)會(huì)啟動(dòng)JVM，這個(gè)時(shí)候在目標(biāo)程序運(yùn)行前會(huì)加載代理客戶端，所以代理客戶端是跟目標(biāo)程序運(yùn)行在同一個(gè)進(jìn)程上。這樣一來(lái)外部請(qǐng)求就通過(guò)代理客戶端間接調(diào)用到JVMTI，這樣的好處是我們可以在客戶端Agent里面定制高級(jí)功能，而且代理客戶端編譯打包成一個(gè)動(dòng)態(tài)鏈接庫(kù)之后可以復(fù)用，提高效率。我們簡(jiǎn)單描述一下代理客戶端Agent的工作流程。
建立代理客戶端首先需要定義Agent的入口函數(shù)，猶如Java類的main方法一樣：
JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *vm, char *options, void *reserved);
然后JVM在啟動(dòng)的時(shí)候就會(huì)把JVMTI的指針JavaVM傳給代理的入口函數(shù)，options則是傳參，有了這個(gè)指針后代理就可以充分調(diào)用JVMTI的函數(shù)了。
//設(shè)置斷點(diǎn),參數(shù)是調(diào)試目標(biāo)方法和行數(shù)位置
jvmtiError SetBreakpoint(jvmtiEnv* env,jmethodID method,jlocation location);
//當(dāng)目標(biāo)程序執(zhí)行到指定斷點(diǎn)，目標(biāo)線程則被掛起
jvmtiError SuspendThread(jvmtiEnv* env,jthread thread);
當(dāng)然除了JVM啟動(dòng)時(shí)可以加載代理，運(yùn)行過(guò)程中也是可以的，這個(gè)下文我們講字節(jié)碼增強(qiáng)還會(huì)再說(shuō)到。
JNIEXPORT jint JNICALL Agent_OnAttach(JavaVM* vm, char *options, void *reserved);
有興趣的同學(xué)可以自己動(dòng)手寫(xiě)一個(gè)Agent試試，通過(guò)調(diào)用JVMTI接口可以實(shí)現(xiàn)自己定制化的調(diào)試工具。
JDWP

上文我們知道調(diào)用JVMTI需要建立一個(gè)代理客戶端，但是假如我建立了包含通用功能的Agent想開(kāi)發(fā)出去給所有調(diào)試器使用，有一種方式是資深開(kāi)發(fā)者通過(guò)閱讀我的文檔后進(jìn)行開(kāi)發(fā)調(diào)用，還有另外一種方式就是我在我的Agent里面加入了JDWP協(xié)議模塊，這樣調(diào)試器就可以不用關(guān)心我的接口細(xì)節(jié)，只需按照閱讀的協(xié)議發(fā)起請(qǐng)求即可。JDWP是調(diào)試器和JVM中間的協(xié)議規(guī)范，類似HTTP協(xié)議一樣，JDWP也定義規(guī)范了握手協(xié)議和報(bào)文格式。
調(diào)試器發(fā)起請(qǐng)求的握手流程：
1）調(diào)試器發(fā)送一段包含“JDWP-Handshake”的14個(gè)bytes的字符串
2）JVM回復(fù)同樣的內(nèi)容“JDWP-Handshake”
完成握手流程后就可以像HTTP一樣向JVM的代理客戶端發(fā)送請(qǐng)求數(shù)據(jù)，同時(shí)回復(fù)所需參數(shù)。請(qǐng)求和回復(fù)的數(shù)據(jù)幀也有嚴(yán)格的結(jié)構(gòu)，請(qǐng)求的數(shù)據(jù)格式為Command Packet，回復(fù)的格式為Reply Packet，包含包頭和數(shù)據(jù)兩部分，具體格式參考官網(wǎng)。實(shí)際上JDWP卻是也是通過(guò)建立代理客戶端來(lái)實(shí)現(xiàn)報(bào)文格式的規(guī)范，也就是JDWP Agent 里面的JDWPTI實(shí)現(xiàn)了JDWP對(duì)協(xié)議的定義。JDWP的功能是由JDWP傳輸接口(Java Debug Wire Protocol Transport Interface)實(shí)現(xiàn)的，具體流程其實(shí)跟JVMTI差不多，也是講JDWPTI編譯打包成代理庫(kù)后，在JVM啟動(dòng)的時(shí)候加載到目標(biāo)進(jìn)程。那么調(diào)試器調(diào)用的過(guò)程就是JDWP Agent接收到請(qǐng)求后，調(diào)用JVMTI Agent，JDWP負(fù)責(zé)定義好報(bào)文數(shù)據(jù)，而JDWPTI則是具體的執(zhí)行命令和響應(yīng)事件。
JDI

前面已經(jīng)解釋了JVMTI和JDWP的工作原理和交互機(jī)制，剩下的就是搞清楚面向用戶的JDI是如何運(yùn)行的。首先JDI位于JPDA的最頂層入口，它的實(shí)現(xiàn)是通過(guò)JAVA語(yǔ)言編寫(xiě)的，所以可以理解為Java調(diào)試客戶端對(duì)JDI接口的封裝調(diào)用，比如我們熟悉的IDE界面啟動(dòng)調(diào)試，或者JAVA的命令行調(diào)試客戶端JDB。
通常我們?cè)O(shè)置好目標(biāo)程序的斷點(diǎn)之后啟動(dòng)程序，然后通過(guò)調(diào)試器啟動(dòng)程序之前，調(diào)試器會(huì)先獲取JVM管理器，然后通過(guò)JVM管理器對(duì)象virtualMachineManager獲取連接器Connector，調(diào)試器與虛擬機(jī)獲得鏈接后就可以啟動(dòng)目標(biāo)程序了。如下代碼：
VirtualMachineManager virtualMachineManager = Bootstrap.virtualMachineManager();
JDI完成調(diào)試需要實(shí)現(xiàn)的功能有三個(gè)模塊：數(shù)據(jù)、鏈接、事件
講解完JPDA體系的實(shí)現(xiàn)原理，我們?cè)俅问崂硪幌抡{(diào)試的整個(gè)流程：
調(diào)試器 —> JDI客戶端 —> JDWP Agent—> JVMTI Agent —>> JVMTI —> Application
8.1.3 實(shí)現(xiàn)

現(xiàn)在我們已經(jīng)對(duì)整個(gè)JPDA結(jié)構(gòu)有了深入理解，接下來(lái)我們就通過(guò)對(duì)這些樸素的原理來(lái)實(shí)現(xiàn)程序的斷點(diǎn)調(diào)試。當(dāng)然我們不會(huì)在這里介紹從IDE的UI斷點(diǎn)調(diào)試的過(guò)程，因?yàn)閷?duì)這套是使用已經(jīng)非常熟悉了，我們知道IDE的UI斷點(diǎn)調(diào)試本質(zhì)上是調(diào)試器客戶端對(duì)JDI的調(diào)用，那我們就通過(guò)一個(gè)調(diào)試的案例來(lái)解釋一下這背后的原理。
搭建服務(wù)

首先我們需要先搭建一個(gè)可供調(diào)試的web服務(wù)，這里我首選springboot+來(lái)搭建，通過(guò)官網(wǎng)生成樣例project或者maven插件都可以，具體的太基礎(chǔ)的就不在這里演示，該服務(wù)只提供一個(gè)Controller包含的一個(gè)簡(jiǎn)單方法。如果使用Tomcat部署，則可以通過(guò)自有的開(kāi)關(guān)catalina jpda start來(lái)啟動(dòng)debug模式。
package com.zooncool.debug.rest;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@RestController("/debug")
public class DebugController {
    @GetMapping
    public String ask(@RequestParam("name") String name) {
        String message = "are you ok?" + name;
        return message;
    }
}
啟動(dòng)服務(wù)

搭建好服務(wù)之后我們先啟動(dòng)服務(wù)，我們通過(guò)maven來(lái)啟動(dòng)服務(wù)，其中涉及到的一些參數(shù)下面解釋。
mvn spring-boot:run -Drun.jvmArguments="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8001"
或者
mvn spring-boot:run -Drun.jvmArguments="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8001"
執(zhí)行完上述命令后，就等著我們調(diào)試器的請(qǐng)求接入到目標(biāo)程序了。
調(diào)試接入

我們知道java的調(diào)試器客戶端為jdb，下面我們就使用jdb來(lái)接入我們的目標(biāo)程序。
#jdb 通過(guò)attach參數(shù)選擇本地目標(biāo)程序，同時(shí)附上目標(biāo)程序的源碼，回想之前我們講到的JDI的鏡像接口，就是把目標(biāo)程序的堆棧結(jié)構(gòu)同步過(guò)來(lái)，如果能我們提供的源碼對(duì)應(yīng)上，那就可以在源碼上面顯示斷點(diǎn)標(biāo)志
$ jdb -attach localhost:8001 -sourcepath /Users/linzhenhua/Documents/repositories/practice/stackify-master/remote-debugging/src/main/java/
設(shè)置未捕獲的java.lang.Throwable
設(shè)置延遲的未捕獲的java.lang.Throwable
正在初始化jdb...

#stop，選擇對(duì)應(yīng)方法設(shè)置斷點(diǎn)
> stop in com.zooncool.debug.rest.DebugController.ask(java.lang.String)
設(shè)置斷點(diǎn)com.zooncool.debug.rest.DebugController.ask(java.lang.String)

#如果我們?cè)O(shè)置不存在的方法為斷點(diǎn)，則會(huì)有錯(cuò)誤提示
> stop in com.zooncool.debug.rest.DebugController.ask2(java.lang.String)
無(wú)法設(shè)置斷點(diǎn)com.zooncool.debug.rest.DebugController.ask2(java.lang.String): com.zooncool.debug.rest.DebugController中沒(méi)有方法ask2

#這時(shí)候我們已經(jīng)設(shè)置完斷點(diǎn)，就可以發(fā)起個(gè)HTTP請(qǐng)求
#http://localhost:7001/remote-debugging/debug/ask?name=Jack
#發(fā)起請(qǐng)求后我們回到j(luò)db控制臺(tái)，觀察是否命中斷點(diǎn)
> 斷點(diǎn)命中: "線程=http-nio-7001-exec-5", com.zooncool.debug.rest.DebugController.ask(), 行=14 bci=0
14            String message = "are you ok?" + name;

#list，對(duì)照源碼，確實(shí)是進(jìn)入ask方法第一行命中斷點(diǎn)，也就是14行，這時(shí)候我們可以查看源碼
http-nio-7001-exec-5[1] list
10    @RestController("/debug")
11    public class DebugController {
12        @GetMapping
13        public String ask(@RequestParam("name") String name) {
14 =>         String message = "are you ok?" + name;
15            return message;
16        }
17    }

#locals，觀察完源碼，我們想獲取name的傳參,跟URL傳入的一致
http-nio-7001-exec-5[1] locals
方法參數(shù):
name = "Jack"
本地變量:

#print name，打印入?yún)?br /> http-nio-7001-exec-5[1] print name
name = "Jack"

#where，查詢方法調(diào)用的棧幀，從web容器入口調(diào)用方法到目標(biāo)方法的調(diào)用鏈路
http-nio-7001-exec-5[1] where
  [1] com.zooncool.debug.rest.DebugController.ask (DebugController.java:14)
  ...
  [55] java.lang.Thread.run (Thread.java:748)
#step，下一步到下一行代碼
http-nio-7001-exec-5[1] step
> 已完成的步驟: "線程=http-nio-7001-exec-5", com.zooncool.debug.rest.DebugController.ask(), 行=15 bci=20
15            return message;

#step up，完成當(dāng)前方法的調(diào)用
http-nio-7001-exec-5[1] step up
> 已完成的步驟: "線程=http-nio-7001-exec-5", sun.reflect.NativeMethodAccessorImpl.invoke(), 行=62 bci=103

#cont,結(jié)束調(diào)試，執(zhí)行完畢
http-nio-7001-exec-5[1] cont
>

#clear，完成調(diào)試任務(wù)，清除斷點(diǎn)
> clear
斷點(diǎn)集:
        斷點(diǎn)com.zooncool.debug.rest.DebugController.ask(java.lang.String)
        斷點(diǎn)com.zooncool.debug.rest.DebugController.ask2(java.lang.String)
#選擇一個(gè)斷點(diǎn)刪除
> clear com.zooncool.debug.rest.DebugController.ask(java.lang.String)
已刪除: 斷點(diǎn)com.zooncool.debug.rest.DebugController.ask(java.lang.String)
我們已經(jīng)完成了命令行調(diào)試的全部流程，stop/list/locals/print name/where/step/step up/cont/clear這些命令其實(shí)就是IDE的UI后臺(tái)調(diào)用的腳本。而這些腳本就是基于JDI層面的接口所提供的能力，下面我們還有重點(diǎn)觀察一個(gè)核心功能，先從頭再設(shè)置一下斷點(diǎn)。
#stop，選擇對(duì)應(yīng)方法設(shè)置斷點(diǎn)
> stop in com.zooncool.debug.rest.DebugController.ask(java.lang.String)
設(shè)置斷點(diǎn)com.zooncool.debug.rest.DebugController.ask(java.lang.String)
#這時(shí)候我們已經(jīng)設(shè)置完斷點(diǎn)，就可以發(fā)起個(gè)HTTP請(qǐng)求
#http://localhost:7001/remote-debugging/debug/ask?name=Jack
#發(fā)起請(qǐng)求后我們回到j(luò)db控制臺(tái)，觀察是否命中斷點(diǎn)
> 斷點(diǎn)命中: "線程=http-nio-7001-exec-5", com.zooncool.debug.rest.DebugController.ask(), 行=14 bci=0
14            String message = "are you ok?" + name;
#print name，打印入?yún)?br /> http-nio-7001-exec-5[1] print name
name = "Jack"
#如果這個(gè)時(shí)候我們想替換掉Jack，換成Lucy
http-nio-7001-exec-6[1] set name = "Lucy"   
name = "Lucy" = "Lucy"
#進(jìn)入下一步
http-nio-7001-exec-6[1] step
> 已完成的步驟: "線程=http-nio-7001-exec-6", com.zooncool.debug.rest.DebugController.ask(), 行=15 bci=20
15            return message;
#查看變量，我們發(fā)現(xiàn)name的值已經(jīng)被修改了
http-nio-7001-exec-6[1] locals
方法參數(shù):
name = "Lucy"
本地變量:
message = "are you ok?Lucy"
至此我們已經(jīng)完成了JPDA的原理解析到調(diào)試實(shí)踐，也理解了JAVA調(diào)試的工作機(jī)制，其中留下一個(gè)重要的彩蛋就是通過(guò)JPDA進(jìn)入調(diào)試模式，我們可以動(dòng)態(tài)的修改JVM內(nèi)存對(duì)象和類的內(nèi)容，這也講引出下文我們要介紹的字節(jié)碼增強(qiáng)技術(shù)。
8.2 熱替換

8.2.1概念

終于來(lái)到熱替換這節(jié)了，前文我們做了好多鋪墊，介紹熱替換之前我們稍稍回顧一下熱部署。我們知道熱部署是“獨(dú)立”于JVM之外的一門對(duì)類加載器應(yīng)用的技術(shù)，通常是應(yīng)用容器借助自定義類加載器的迭代，無(wú)需重啟JVM缺能更新代碼從而達(dá)到熱部署，也就是說(shuō)熱部署是JVM之外容器提供的一種能力。而本節(jié)我們介紹的熱替換技術(shù)是實(shí)打?qū)岼VM提供的能力，是JVM提供的一種能夠?qū)崟r(shí)更新內(nèi)存類結(jié)構(gòu)的一種能力，這種實(shí)時(shí)更新JVM方法區(qū)類結(jié)構(gòu)的能力當(dāng)然也是無(wú)需重啟JVM實(shí)例。
熱替換HotSwap是Sun公司在Java 1.4版本引入的一種新實(shí)驗(yàn)性技術(shù)，也就是上一節(jié)我們介紹JPDA提到的調(diào)試模式下可以動(dòng)態(tài)替換類結(jié)構(gòu)的彩蛋，這個(gè)功能被集成到JPDA框架的接口集合里面，首先我們定義好熱替換的概念。
熱替換(HotSwap)：使用字節(jié)碼增強(qiáng)技術(shù)替換JVM內(nèi)存里面類的結(jié)構(gòu)，包括對(duì)應(yīng)類的對(duì)象，而不需要重啟虛擬機(jī)。
8.2.2原理

前文從宏觀上介紹了JVM實(shí)例的內(nèi)存布局和垃圾回收機(jī)制，微觀上也解釋了類的結(jié)構(gòu)和類加載機(jī)制，上一節(jié)又學(xué)習(xí)了JAVA的調(diào)試框架，基本上我們對(duì)JVM的核心模塊都已經(jīng)摸透了，剩下的就是攻克字節(jié)碼增強(qiáng)的技術(shù)了。而之前講的字節(jié)碼增強(qiáng)技術(shù)也僅僅是放在JPDA里面作為實(shí)驗(yàn)性技術(shù)，而且僅僅局限在方法體和變量的修改，無(wú)法動(dòng)態(tài)修改方法簽名或者增刪方法，因?yàn)樽止?jié)碼增強(qiáng)涉及到垃圾回收機(jī)制，類結(jié)構(gòu)變更，對(duì)象引用，即時(shí)編譯等復(fù)雜問(wèn)題。在HotSwap被引進(jìn)后至今，JCP也未能通過(guò)正式的字節(jié)碼增強(qiáng)實(shí)現(xiàn)。
JAVA是一門靜態(tài)語(yǔ)言，而字節(jié)碼增強(qiáng)所要達(dá)的效果就是讓Java像動(dòng)態(tài)語(yǔ)言一樣跑起來(lái)，無(wú)需重啟服務(wù)器。下面我們介紹字節(jié)碼增強(qiáng)的基本原理。
8.2.3實(shí)現(xiàn)

但是盡管字節(jié)碼增強(qiáng)是一門復(fù)雜的技術(shù)，這并不妨礙我們進(jìn)一步的探索，下面我們介紹幾種常見(jiàn)的實(shí)現(xiàn)方案。
具體的我會(huì)挑兩個(gè)具有代表性的工具深入講解，篇幅所限，這里就補(bǔ)展開(kāi)了。
9.總結(jié)

JVM是程序發(fā)展至今的一顆隗寶，是程序設(shè)計(jì)和工程實(shí)現(xiàn)的完美結(jié)合。JVM作為作為三大工業(yè)級(jí)程序語(yǔ)言為首JAVA的根基，本文試圖在瀚如煙海的JVM海洋中找出其中最耀眼的冰山，并力求用簡(jiǎn)潔的邏輯線索把各個(gè)冰山串起來(lái)，在腦海中對(duì)JVM的觀感有更加立體的認(rèn)識(shí)。更近一步的認(rèn)識(shí)JVM對(duì)程序設(shè)計(jì)的功力提示大有裨益，而本文也只是將海平面上的冰山鏈接起來(lái)，但這只是冰山一角，JVM更多的底層設(shè)計(jì)和實(shí)現(xiàn)細(xì)節(jié)還遠(yuǎn)遠(yuǎn)沒(méi)有涉及到，而且也不乏知識(shí)盲區(qū)而沒(méi)有提及到的，路漫漫其修遠(yuǎn)兮，JVM本身也在不斷的推陳出新，借此機(jī)會(huì)總結(jié)出JVM的核心體系，以此回顧對(duì)JVM知識(shí)的查漏補(bǔ)缺，也是一次JVM的認(rèn)知升級(jí)。最后還是例牌來(lái)兩張圖結(jié)束JVM的介紹，希望對(duì)更的同學(xué)有幫助。

(, 下載次數(shù): 5)

(, 下載次數(shù): 7)

-----------------------------



歡迎光臨 愛(ài)鋒貝 (http://m.7gfy2te7.cn/) Powered by Discuz! X3.4