### 一 class的熱替換

ClassLoader中重要的方法

**loadClass**
`ClassLoader.loadClass(...)` 是ClassLoader的入口點。當一個類沒有指明用什麼載入器載入的時候，JVM預設採用AppClassLoader載入器載入沒有載入過的class，呼叫的方法的入口就是loadClass(…)。如果一個class被自定義的ClassLoader載入，那麼JVM也會呼叫這個自定義的ClassLoader.loadClass(…)方法來載入class內部引用的一些別的class檔案。過載這個方法，能實現自定義載入class的方式，拋棄雙親委託機制，但是即使不採用雙親委託機制，比如java.lang包中的相關類還是不能自定義一個同名的類來代替，主要因為JVM解析、驗證class的時候，會進行相關判斷。

**defineClass**
系統自帶的ClassLoader，預設載入程式的是AppClassLoader，ClassLoader載入一個class，最終呼叫的是defineClass(…)方法，這時候就在想是否可以重複呼叫defineClass(…)方法載入同一個類(或者修改過)，最後發現呼叫多次的話會有相關錯誤:

```
java.lang.LinkageError 
attempted duplicate class definition
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

所以**一個class被一個ClassLoader例項載入過的話，就不能再被這個ClassLoader例項再次載入**(這裡的載入指的是，呼叫了defileClass(…)放方法，重新載入位元組碼、解析、驗證。)。而系統預設的AppClassLoader載入器，他們內部會快取載入過的class，重新載入的話，就直接取快取。所與對於熱載入的話，只能重新建立一個ClassLoader，然後再去載入已經被載入過的class檔案。

### 二 class解除安裝

在Java中class也是可以unload。**JVM中class和Meta資訊存放在PermGen space區域**。如果載入的class檔案很多，那麼可能導致PermGen space區域空間溢位。引起：java.lang.OutOfMemoryErrorPermGen space. 對於有些Class我們可能只需要使用一次，就不再需要了，也可能我們修改了class檔案，我們需要重新載入 newclass，那麼oldclass就不再需要了。那麼JVM怎麼樣才能解除安裝Class呢。

JVM中的Class只有滿足以下三個條件，才能被GC回收，也就是該Class被解除安裝（unload）：

> *   該類所有的例項都已經被GC。
> *   載入該類的ClassLoader例項已經被GC。
> *   該類的java.lang.Class物件沒有在任何地方被引用。

GC的時機我們是不可控的，那麼同樣的我們對於Class的解除安裝也是不可控的。

```
1、有啟動類載入器載入的型別在整個執行期間是不可能被解除安裝的(jvm和jls規範).
2、被系統類載入器和標準擴充套件類載入器載入的型別在執行期間不太可能被解除安裝，因為系統類載入器例項或者標準擴充套件類的例項基本上在整個執行期間總能直接或者間接的訪問的到，其達到unreachable的可能性極小.(當然，在虛擬機器快退出的時候可以，因為不管ClassLoader例項或者Class(java.lang.Class)例項也都是在堆中存在，同樣遵循垃圾收集的規則).
3、被開發者自定義的類載入器例項載入的型別只有在很簡單的上下文環境中才能被解除安裝，而且一般還要藉助於強制呼叫虛擬機器的垃圾收集功能才可以做到.可以預想，稍微複雜點的應用場景中(尤其很多時候，使用者在開發自定義類載入器例項的時候採用快取的策略以提高系統效能)，被載入的型別在執行期間也是幾乎不太可能被解除安裝的(至少解除安裝的時間是不確定的).
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

綜合以上三點， 一個已經載入的型別被解除安裝的機率很小至少被解除安裝的時間是不確定的.同時，我們可以看的出來，開發者在開發程式碼時候，不應該對虛擬機器的型別解除安裝做任何假設的前提下來實現系統中的特定功能.

### 三 Tomcat中關於類的載入與解除安裝

Tomcat中與其說有熱載入，還不如說是熱部署來的準確些。因為對於一個應用，其中class檔案被修改過，那麼Tomcat會先解除安裝這個應用(Context)，然後重新載入這個應用，其中關鍵就在於自定義ClassLoader的應用。這裡有篇文章很好的介紹了tomcat中對於ClassLoader的應用。

Tomcat啟動的時候，ClassLoader載入的流程：

> 1 Tomcat啟動的時候，用system classloader即AppClassLoader載入`{catalina.home}/bin`裡面的jar包，也就是tomcat啟動相關的jar包。 2 Tomcat啟動類Bootstrap中有3個classloader屬性，catalinaLoader、commonLoader、sharedLoader在Tomcat7中預設他們初始化都為同一個StandardClassLoader例項。具體的也可以在`{catalina.home}/bin/bootstrap.jar`包中的catalina.properites中進行配置。 3 StandardClassLoader載入`{catalina.home}/lib`下面的所有Tomcat用到的jar包。 4 一個Context容器，代表了一個app應用。Context–>WebappLoader–>WebClassLoader。並且Thread.contextClassLoader=WebClassLoader。應用程式中的jsp檔案、class類、lib/*.jar包，都是WebClassLoader載入的。

當Jsp檔案修改的時候，Tomcat更新步驟：

> 1 但訪問1.jsp的時候，1.jsp的包裝類JspServletWrapper會去比較1.jsp檔案最新修改時間和上次的修改時間，以此判斷1.jsp是否修改過。 2 1.jsp修改過的話，那麼jspservletWrapper會清除相關引用，包括1.jsp編譯後的servlet例項和載入這個servlet的JasperLoader例項。 3 重新建立一個JasperLoader例項，重新載入修改過後的1.jsp，重新生成一個Servlet例項。 4 返回修改後的1.jsp內容給使用者。

當app下面的class檔案修改的時候，Tomcat更新步驟：

> 1 Context容器會有專門執行緒監控app下面的類的修改情況。 2 如果發現有類被修改了。那麼呼叫Context.reload()。清楚一系列相關的引用和資源。 3 然後創新建立一個WebClassLoader例項，重新載入app下面需要的class。

在一個有一定規模的應用中，如果檔案修改多次，重啟多次的話，`java.lang.OutOfMemoryErrorPermGen space`這個錯誤的的出現非常頻繁。主要就是因為每次重啟重新載入大量的class，超過了PermGen space設定的大小。兩種情況可能導致PermGen space溢位。 一、GC(Garbage Collection)在主程式執行期對PermGen space沒有進行清理(GC的不可控行)， 二、重啟之前WebClassLoader載入的class在別的地方還存在著引用。

原文地址：http://www.blogjava.net/heavensay/archive/2012/11/07/389685.html

> 在 Java 開發領域，熱部署一直是一個難以解決的問題，目前的 Java 虛擬機器只能實現方法體的修改熱部署，對於整個類的結構修改，仍然需要重啟虛擬機器，對類重新載入才能完成更新操作。對於某些大型的應用來說，每次的重啟都需要花費大量的時間成本。雖然 osgi 架構的出現，讓模組重啟成為可能，但是如果模組之間有呼叫關係的話，這樣的操作依然會讓應用出現短暫的功能性休克。本文將探索如何在不破壞 Java 虛擬機器現有行為的前提下，實現某個單一類的熱部署，讓系統無需重啟就完成某個類的更新。

### 類載入的探索

首先談一下何為熱部署（hotswap），**熱部署是在不重啟 Java 虛擬機器的前提下，能自動偵測到 class 檔案的變化，更新執行時 class 的行為**。Java 類是透過 Java 虛擬機器載入的，某個類的 class 檔案在被 classloader 載入後，會生成對應的 Class 物件，之後就可以建立該類的例項。**預設的虛擬機器行為只會在啟動時載入類，如果後期有一個類需要更新的話，單純替換編譯的 class 檔案，Java 虛擬機器是不會更新正在執行的 class**。如果要實現熱部署，最根本的方式是修改虛擬機器的原始碼，改變 classloader 的載入行為，使虛擬機器能監聽 class 檔案的更新，重新載入 class 檔案，這樣的行為破壞性很大，為後續的 JVM 升級埋下了一個大坑。

另一種友好的方法是建立自己的 `classloader` 來載入需要監聽的 class，這樣就能控制類載入的時機，從而實現熱部署。本文將具體探索如何實現這個方案。首先需要了解一下 Java 虛擬機器現有的載入機制。目前的載入機制，稱為**雙親委派**，系統在使用一個 `classloader` 來載入類時，會先詢問當前 `classloader` 的父類是否有能力載入，如果父類無法實現載入操作，才會將任務下放到該 `classloader` 來載入。這種自上而下的載入方式的好處是，讓每個 `classloader` 執行自己的載入任務，不會重複載入類。**但是這種方式卻使載入順序非常難改變，讓自定義 `classloader` 搶先載入需要監聽改變的類成為了一個難題。**

不過我們可以換一個思路，雖然無法搶先載入該類，但是仍然可以用自定義 classloader 建立一個功能相同的類，讓每次例項化的物件都指向這個新的類。當這個類的 class 檔案發生改變的時候，再次建立一個更新的類，之後如果系統再次發出例項化請求，建立的物件講指向這個全新的類。

下面來簡單列舉一下需要做的工作。

```
建立自定義的 classloader，載入需要監聽改變的類，在 class 檔案發生改變的時候，重新載入該類。
改變建立物件的行為，使他們在建立時使用自定義 classloader 載入的 class。
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

### 自定義載入器的實現

自定義載入器仍然需要執行類載入的功能。這裡卻存在一個問題，**同一個類載入器無法同時載入兩個相同名稱的類**，由於不論類的結構如何發生變化，生成的類名不會變，而 **classloader 只能在虛擬機器停止前銷燬已經載入的類**，這樣 classloader 就無法載入更新後的類了。這裡有一個小技巧，讓每次載入的類都儲存成一個帶有版本資訊的 class，比如載入 Test.class 時，儲存在記憶體中的類是 Test_v1.class，當類發生改變時，重新載入的類名是 Test_v2.class。但是真正執行載入 class 檔案建立 class 的 defineClass 方法是一個 native 的方法，修改起來又變得很困難。所以面前還剩一條路，那就是直接修改編譯生成的 class 檔案。

**利用 ASM 修改 class 檔案**

可以修改位元組碼的框架有很多，比如 ASM，CGLIB。本文使用的是 ASM。先來介紹一下 class 檔案的結構，class 檔案包含了以下幾類資訊:

> 第一個是類的基本資訊，包含了訪問許可權資訊，類名資訊，父類資訊，介面資訊。
> 第二個是類的變數資訊。
> 第三個是方法的資訊。

ASM 會先載入一個 class 檔案，然後嚴格順序讀取類的各項資訊，使用者可以按照自己的意願定義增強元件修改這些資訊，最後輸出成一個新的 class。

首先看一下如何利用 ASM 修改類資訊。
清單 1\. 利用 ASM 修改位元組碼

```
    ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS); 
    ClassReader cr = null;     
    String enhancedClassName = classSource.getEnhancedName(); 
    try { 
        cr = new ClassReader(new FileInputStream( 
                classSource.getFile())); 
    } catch (IOException e) { 
        e.printStackTrace(); 
        return null; 
    } 
    ClassVisitor cv = new EnhancedModifier(cw, 
            className.replace(".", "/"), 
            enhancedClassName.replace(".", "/")); 
    cr.accept(cv, 0);
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

ASM 修改位元組碼檔案的流程是一個責任鏈模式，首先使用一個 ClassReader 讀入位元組碼，然後利用 ClassVisitor 做個性化的修改，最後利用 ClassWriter 輸出修改後的位元組碼。

之前提過，需要將讀取的 class 檔案的類名做一些修改，載入成一個全新名字的派生類。這裡將之分為了 2 個步驟。

**第一步，先將原來的類變成介面。**
清單 2\. 重定義的原始類

```
public Class> redefineClass(String className){ 
    ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS); 
    ClassReader cr = null; 
    ClassSource cs = classFiles.get(className); 
    if(cs==null){ 
        return null; 
    } 
    try { 
        cr = new ClassReader(new FileInputStream(cs.getFile())); 
    } catch (IOException e) { 
        e.printStackTrace(); 
        return null; 
    } 
    ClassModifier cm = new ClassModifier(cw); 
    cr.accept(cm, 0); 
    byte[] code = cw.toByteArray(); 
    return defineClass(className, code, 0, code.length); 
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

}

首先 load 原始類的 class 檔案，此處定義了一個增強元件 ClassModifier，作用是修改原始類的型別，將它轉換成介面。原始類的所有方法邏輯都會被去掉。

**第二步，生成的派生類都實現這個介面，即原始類，並且複製原始類中的所有方法邏輯。**之後如果該類需要更新，會生成一個新的派生類，也會實現這個介面。這樣做的目的是不論如何修改，同一個 class 的派生類都有一個共同的介面，他們之間的轉換變得對外不透明。
清單 3\. 定義一個派生類

```
// 在 class 檔案發生改變時重新定義這個類
private Class> redefineClass(String className, ClassSource classSource){ 
    ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_MAXS); 
    ClassReader cr = null; 
    classSource.update(); 
    String enhancedClassName = classSource.getEnhancedName();       
    try { 
        cr = new ClassReader( 
                new FileInputStream(classSource.getFile())); 
    } catch (IOException e) { 
        e.printStackTrace(); 
        return null; 
    } 
    EnhancedModifier em = new EnhancedModifier(cw, className.replace(".", "/"), 
            enhancedClassName.replace(".", "/")); 
    ExtendModifier exm = new ExtendModifier(em, className.replace(".", "/"), 
            enhancedClassName.replace(".", "/")); 
    cr.accept(exm, 0); 
    byte[] code = cw.toByteArray(); 
    classSource.setByteCopy(code); 
    Class> clazz = defineClass(enhancedClassName, code, 0, code.length); 
    classSource.setClassCopy(clazz); 
    return clazz; 
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

}

再次 load 原始類的 class 檔案，此處定義了兩個增強元件，一個是 EnhancedModifier，這個增強元件的作用是改變原有的類名。第二個增強元件是 ExtendModifier，這個增強元件的作用是改變原有類的父類，讓這個修改後的派生類能夠實現同一個原始類（此時原始類已經轉成介面了）。

自定義 classloader 還有一個作用是監聽會發生改變的 class 檔案，classloader 會管理一個定時器，定時依次掃描這些 class 檔案是否改變。

### 改變建立物件的行為

Java 虛擬機器常見的建立物件的方法有兩種，一種是靜態建立，直接 new 一個物件，一種是動態建立，透過反射的方法，建立物件。

由於已經在自定義載入器中更改了原有類的型別，把它從類改成了介面，所以這兩種建立方法都無法成立。我們要做的是將例項化原始類的行為變成例項化派生類。

對於第一種方法，需要做的是將靜態建立，變為透過 classloader 獲取 class，然後動態建立該物件。
清單 4\. 替換後的指令集所對應的邏輯

// 原始邏輯
Greeter p = new Greeter();
// 改變後的邏輯
IGreeter p = (IGreeter)MyClassLoader.getInstance().
findClass(“com.example.Greeter”).newInstance();

這裡又需要用到 ASM 來修改 class 檔案了。查詢到所有 new 物件的語句，替換成透過 classloader 的形式來獲取物件的形式。

清單 5\. 利用 ASM 修改方法體

```
@Override 
public void visitTypeInsn(int opcode, String type) { 
    if(opcode==Opcodes.NEW && type.equals(className)){ 
        List<localvariablenode> variables = node.localVariables; 
        String compileType = null; 
        for(int i=0;i<variables.size localvariablenode="" localvariable="variables.get(i);" compiletype="formType(localVariable.desc);" if="" valiableindexused="" true="" break="" mv.visitmethodinsn="" classload_type="" mv.visitldcinsn="" mv.visittypeinsn="" flag="true;" else="" type="" class.forname="" classloader.findclass="" javaagent="" jvm="" classpath="" class="" linkageerror="" exception="" jdk1.4="" jdk="" classloader="" jdk5.0="" premain="" public="" reloadagent="" static="" void="" agentargs="" instrumentation="" inst="" generaltransformer="" trans="new" inst.addtransformer="" manifest="" premain-class="" jar="" manifest-version:="" premain-class:="" com.example.reloadagent="" can-redefine-classes:="" test="" project="" java="" classfiletransformer="" byte="" transform="" paramclassloader="" string="" paramstring=""> paramClass, ProtectionDomain paramProtectionDomain, 
     byte [] paramArrayOfByte) throws IllegalClassFormatException { 
    String className = paramString.replace("/", "."); 
    if(className.equals("com.example.Test")){ 
        MyClassLoader cl = MyClassLoader.getInstance(); 
        cl.defineReference(className, "com.example.Greeter"); 
        return cl.getByteCode(className); 
    }else if(className.equals("com.example.Greeter")){ 
        MyClassLoader cl = MyClassLoader.getInstance(); 
        cl.redefineClass(className); 
        return cl.getByteCode(className); 
    } 
    return null; 
 }
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

至此，所有的工作大功告成，欣賞一下 hotswap 的結果吧。

原文地址：http://www.ibm.com/developerworks/cn/java/j-lo-hotdeploy/

## [java的熱部署和熱載入](https://www.cnblogs.com/wchukai/p/5651172.html "java的熱部署和熱載入")

ps:熱部署和熱載入其實是兩個類似但不同的概念，之前理解不深，so，這篇文章重構了下。

###

一、熱部署與熱載入

在應用執行的時升級軟體，無需重新啟動的方式有兩種，熱部署和熱載入。

對於Java應用程式來說，熱部署就是在伺服器執行時重新部署專案，熱載入即在在執行時重新載入class，從而升級應用。

###

二、實現原理

熱載入的實現原理主要依賴java的類載入機制，在實現方式可以概括為在容器啟動的時候起一條後臺執行緒，定時的檢測類檔案的時間戳變化，如果類的時間戳變掉了，則將類重新載入。

對比反射機制，反射是在執行時獲取類資訊，透過動態的呼叫來改變程式行為；
熱載入則是在執行時透過重新載入改變類資訊，直接改變程式行為。

熱部署原理類似，但它是直接重新載入整個應用，這種方式會釋放記憶體，比熱載入更加乾淨徹底，但同時也更費時間。

###

三、在java中應用

1.生產環境

熱部署作為一個比較靈活的機制，在實際的生產上運用還是有，但相對很少，熱載入則基本沒有應用。分析如下

*   一、安全性

熱載入這種直接修改jvm中位元組碼的方式是難以監控的，不同於sql等執行可以記錄日誌，直接位元組碼的修改幾乎無法記錄程式碼邏輯的變化，對既有程式碼行為的影響難以控制，對於越注重安全的應用，熱載入帶來的風險越大,這好比給飛行中的飛機更換髮動機。

*   二、適用的情景

技術大部分是跟需求掛鉤的，而需要熱部署的情景很少。

1.  頻繁的部署並且啟動耗時長的應用
2.  無法停止服務的應用

在生產中，並沒有需要頻繁部署的應用，即使是敏捷，再快也是一週一次的迭代，並且透過業務劃分和模組化程式設計，部署的代價完全可以忽略不計，對於現有的應用，啟動耗時再長，也並非長到無法忍受，如果真的這麼長，那更應該考慮的是如何進行模組拆分，分散式部署了。

對於無法停止服務的應用，比如現在的雲端計算平臺這樣分散式應用，採用分批上線也可以滿足需求，類似熱部署方案應該是放在最後考慮的解決方案。

###

2.開發環境

在生產中，不會有頻繁的部署並且啟動耗時長的應用，但由於雲端計算的興起，熱部署還是有其應用。
而熱載入有點玩火，太危險了。但在開發和debug中，頻繁啟動應用卻隨處可見，熱載入機制可以極大的提升開發效率。這兩種機制，在開發中還有另外一種稱呼—開發者模式。

對於大型專案：往往啟/停需要等待幾分鐘時間。更浪費時間的是，對於一個類中的方法的除錯過程，如果修改多次，需要反覆的啟停伺服器，浪費的時間更多。

以目前的crm專案為例，其啟動時間為5m，以一天debug重啟十次，一個月工作20天來算，每年重啟耗時25人日，如果能完全使用熱載入，每年節省重啟時間近1人月。

_crm pool啟動耗時_

1.struts2熱載入

在struts2中熱載入即開發者模式，在struts.xml配置

```
<constant name="struts.devMode" value="true"></constant>

```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

從而當更改struts.xml檔案後不需要重新啟動伺服器就可以進行程式除錯。

2.開發時使用tomcat熱載入

tomcat本身預設開啟了熱部署方式，但熱部署是直接重新載入整個應用，耗時跟重啟伺服器差不多，我們需要的其實是熱載入，即修改了哪個class，只重新載入這一個class，這樣耗時幾乎為0。
對於tomcat5.x 以上版本，均已支援一定程度上得熱載入，但這種方式只針對程式碼行級別的，也就是說如果新刪方法，註解，類，或者變數時是無效的，只能重啟，這是我目前在公司開發時用的方式，可以顯著降低debug時的重啟次數，提高開發效率

1.將tomcat server.xml檔案的**context reloadable** 值置為**false** 或者在web modules中編輯取消Auto reloading選項。

```
    <context reloadable="false"></context>

```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

2.修改eclipse中的server配置

這樣做可以在在修改程式碼之後，不會自動重啟伺服器，而只載入程式碼，新增一行java程式碼ctrl+s後直接重新整理頁面或呼叫介面即可看到效果，無需重啟tomcat。

3.遠端debug中使用tomcat熱載入

tomcat的熱載入機制不僅可以在本地debug時，tomcat的遠端除錯也支援熱部署，透過eclipse debug遠端到遠端tomcat上，修改原生程式碼，ctrl+s後直接重新整理頁面後呼叫介面，即可發現遠端tomcat已將原生程式碼進行了熱載入。

4.jrebel外掛方式

jrebel外掛可以進行更徹底的熱載入，不僅包括類，甚至支援spring 等配置檔案的熱載入，但公司專案開發環境複雜，目前在eclipse中配置一直沒有成功，只能使用tomcat自帶的熱載入機制。

###

總結

在實際生產中熱部署在雲端計算中運用挺多，但熱載入沒有，而在開發中，熱載入可以顯著的提升工作效率，強烈推薦使用熱載入方式，不僅tomcat，大多數其他servlet容器也支援這種方式，大家可以自行搜尋相關技巧。

參考文件 ：

[1.Tomcat 熱部署實現方式原始碼分析總結](http://my.oschina.net/heroShane/blog/198492 "1.Tomcat 熱部署實現方式原始碼分析總結")

[2.提高開發效率-jrebel外掛安裝](http://blog.csdn.net/lzz313/article/details/6681590 "2.提高開發效率-jrebel外掛安裝")

HotSwap和JRebel原理

### HotSwap和Instrumentation

在2002年的時候，Sun在Java 1.4的JVM中引入了一種新的被稱作`HotSwap`的實驗性技術，這一技術被合成到了`Debugger API`內部，其允許除錯者使用同一個類標識來更新類的位元組碼。這意味著所有物件都可以引用一個更新後的類，並在它們的方法被呼叫的時候執行新的程式碼，這就避免了無論何時只要有類的位元組碼被修改就要過載容器的這種要求。所有新式的IDE（包括Eclipse、IDEA和NetBeans）都支援這一技術，從Java 5開始，這一功能還透過`Instrumentation API`直接提供給Java應用使用。

[![hotswap](https://img-blog.csdnimg.cn/img_convert/5b8d7bd475788c28917e16b1e6ec5003.png)](http://www.hollischuang.com/wp-content/uploads/2015/10/hotswap.png)

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

不幸的是，這種重定義僅限於修改方法體——除了方法體之外，它既不能新增方法或域，也不能修改其他任何東西。這限制了HotSwap的實用性，且其還因其他的一些問題而變得更糟：

> Java編譯器常常會建立合成的方法或是域，儘管你僅是修改了一個方法體（比如說，在新增一個類字面常量（class literal）、匿名的和內部的類的時候等等）。 在除錯模式下執行常常會降低應用的速度或是引入其他的問題。

這些情況導致了HotSwap很少被使用，較之應該可能被使用的頻度要低。

### 為什麼HotSwap僅限於對方法體起作用？

自從引入了HotSwap之後，在最近的10年，這一問題已經被問了非常多次。在支援做整組改變的JVM呼叫的bug中，這是一個得票率最高的bug ，但到目前為止，這一問題一直沒有被落實。

一個宣告：我不能說是一個JVM專家，我對JVM是如何實現的在總體上有著一個很好的理解，這幾年來我有和少數幾個（前）Sun工程師談過，不過我並沒有驗證我在這裡說的每一件事情。不過話雖如此，對於這個bug依然處開發狀態的原因我確實是有一些想法的（不過如果你更清楚其中的原因的話，歡迎指正）。

JVM是一種做了重度最佳化的軟體，執行在多個平臺上。效能和穩定性是其最高的優先事項。為了在不同的環境中支援這些事項，Sun的JVM提供了這樣的功能特色：

```
 兩個重度最佳化的即時編譯器（-client和-server）
 幾個多代（multi-generational ）垃圾收集器
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

這些功能特性使得類模式（schema）的發展變成了一個相當大的挑戰。為了理解這其中的原因，我們需要稍微靠近一點看一看，到底是需要用什麼來支援方法和域的新增操作（甚至更深入一些，修改繼承的層次結構）。

在被載入到JVM中時，物件是由記憶體中的結構來表示的，結構佔據了某個特定大小（它的域加上後設資料）的連續的記憶體區域。為了新增一個域，我們需要調整結構的大小，但因為臨近的區域可能已被佔用，我們就需要把整個結構重新分配到一個不同的區域中，這一區域中有足夠可用的空間來把它填寫進來。現在，由於我們實際上是更新了一個類（並不僅是某個物件），所以我們不得不對該類的每一個物件都做這樣的一件事。

這本身並不難實現——Java垃圾收集器就已經是隨時都在做重分配物件的工作的了。問題是，一個“堆”的抽象就僅是一個抽象而已。記憶體的實際佈局取決於當前活動的垃圾收集器，而且，為了能與所有這些物件相容，重分配應該有可能會被委派給活動的垃圾收集器。JVM在重分配期間還需要掛起，因此其在此期間同時進行GC工作也是合理的。

新增一個方法並不要求更新物件的結構，但確實是需要更新類的結構的，這也會體現在堆上。不過考慮一下這種情況：從類被載入之後的那一刻起，其從本質上來說就是被永久凍結了的。這使得JIT（Just-In-Time）能夠完成JVM執行的主要最佳化操作——內聯。應用程式熱點中的大多數方法呼叫會被取消，這些程式碼會被複製到對其做呼叫的方法中。一個簡單的檢測會被插進來，用以確保目標物件確實是我們所認為的物件。

於是就有了這樣可笑的事：在我們能夠新增方法到類中的時候，這種“簡單的檢查”是不夠的。我們需要的是一個相當複雜的檢查，需要這樣更復雜的檢查來確保沒有使用了相同名字的方法被新增到目標類以及目標類的超類中。另外，我們也可以跟蹤所有的內聯點和它們的依賴，並在類被更新時，解除對它們所做的最佳化。兩種方式可選擇，或是付出效能方面的代價，或是帶來更高的複雜性。

最重要的是，考慮到我們正在討論的是有著不同的記憶體模型和指令集的多個平臺，它們可能多多少少需要一些特定的處理，因此你給自己帶來的是一個代價過高而沒有太多投資回報的問題。

[![jrebel-agent](https://img-blog.csdnimg.cn/img_convert/c32c0ff960d1786d35f2888c0229f341.png)](http://www.hollischuang.com/wp-content/uploads/2015/10/jrebel-agent.png)

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

### JRebel介紹

2007年，ZeroTurnaround宣佈提供一種被稱作JRebel（當時是JavaRebel）的工具，該工具可以在無需動態類載入器的情況下更新類，且只做極少的限制。不像HotSwap要依賴於IDE的整合，這一工具的工作方式是，監控磁碟上實際已編譯的.class檔案，無論何時只要有檔案被更新就更新類。這意味著如果願意的話，你可以把JRebel和文字編輯器、命令列的編譯器放在一起使用。當然，它也被巧妙地整合到了Eclipse、InteliJ和NetBeans中。與動態的類載入器不一樣，JRebel保留了所有現有的物件和類的標識和狀態，允許開發者繼續使用他們的應用而不會產生延遲。

### 如何使之生效？

對於初學者來說，JRebel工作在與HotSwap不同的一個抽象層面上。鑑於HotSwap是工作在虛擬機器層面上，且依賴於JVM的內部運作，JRebel用到了JVM的兩個顯著的功能特徵——抽象的位元組碼和類載入器。類載入器允許JRebel辨別出類被載入的時刻，然後實時地翻譯位元組碼，用以在虛擬機器和可執行程式碼之間建立另一個抽象層。

也有人使用這一功能特性來提供分析器、效能監控、後續（continuation）、軟體事務性記憶體以及甚至是分散式的堆。 把位元組碼抽象和類載入器結合在一起，這是一種強大的組合，可被用來實現各種比類過載還要不尋常的功能。當我們越是深入地研究這一問題，我們就會看到面臨的挑戰並不僅是在類過載這件事上，而且是還要在效能和相容性方面沒有明顯退化的情況下來做這件事情，

正如我們在Reloading Java Classes 101 一文中所做的回顧一樣，過載類存在的問題是，一旦類被載入，它就不能被解除安裝或是改變；但是隻要我們願意，我們就可以自由地載入新的類。為了理解在理論上我們是如何過載類的，讓我們來研究一下Java平臺上的動態語言。具體來說，讓我們先來看一看JRudy（我們做了許多的簡化，以免對任何重要人物造成折磨）。

儘管JRuby以“類（class）”作為其功能特性，但在執行時，其每個物件都是動態的，任何時候都可以加入新的域和方法。這意味著JRuby物件與Map沒有什麼兩樣，有著從方法名字到方法實現的對映，以及域名到其值的對映。這些方法的實現被包含在匿名的類中，在遇到方法時這些類就會被生成。如果你新增了一個方法，則所有JRuby要做的事情就是生成一個新的匿名類，該類包含了這一方法的方法體。因為每個匿名類都有一個唯一的名稱，因此在載入該類是不會有問題的，而這樣做的結果是，應用被實時動態地更新了。

從理論上來說，由於位元組碼翻譯通常是用來修改類的位元組碼，因此若僅僅是為了根據需要建立足夠多的類來履行類的功能的話，我們沒有什麼理由不能使用類中的資訊。這樣的話，我們就可以使用如JRuby所做的相同轉換來把所有的Java類分割成持有者類和方法體類。不幸的是，這樣的一種做法會遭受（至少是）如下的問題：

> **效能。**這樣的設定將意味著，每個方法呼叫都會遭遇重定向。我們可以做最佳化，但應用程式的速度將會變慢至少一個數量級，記憶體的使用也會扶搖直上，因為有這麼多的類被建立。 **Java的SDK類**。Java SDK中的類明顯地比應用或是庫中的類更加難以處理。此外它們通常會以本地的程式碼來實現，因此不能以“JRuby”的方式做轉換。然而，如果我們讓它們保持原樣的話，那麼就會引發各種的不相容性錯誤，這些錯誤有可能是無法繞開的。 **相容性。**儘管Java是一種靜態的語言，但是它包含了一些動態的特性，比如說反射和動態代理等。如果我們採用了“JRuby”式的轉換的話，這些功能特性就會失效，除非我們使用自己的類來替換掉Reflection API，而這些類知道這些要做的轉換。

因此，JRebel並沒有採用這樣的做法。相反，其使用了一種更復雜的方法，基於先進的編譯技術，留給我們一個主類和幾個匿名的支援類，這些類由JIT的轉換執行時做支援，其允許所進行的修改不會帶來任何明顯的效能或是相容性的退化。它還

```
留有儘可能多完整的方法呼叫，這意味著JRebel把效能開銷降低到了最小，使其輕量級化。
避免了改編（instrument）Java SDK，除了少數幾個需要保持相容性的地方外。
調整Reflection API的結果，這樣我們就能夠把這些結果中已新增/已刪除的成員正確地包含進來。這也意味著註解（Annotation）的改變對於應用來說是可見的。
```

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

### 除了類過載之外——還有歸檔檔案

過載類是一件Java開發者已經抱怨了很久的事情，不過一旦我們解決了它之後，另外的一些問題就隨之而來了。

Java EE標準的制定並未怎麼關注開發的週轉期（Turnaround）（指的是從對程式碼做修改到觀察到改變在應用中造成的影響這一過程所花費的時間）。其設想的是，所有的應用和它們的模組都被打包到歸檔檔案（JAR、WAR和EAR）中，這意味著在能夠更新應用中的任何檔案之前，你需要更新歸檔檔案——這通常是一個代價高昂的操作，涉及了諸如Ant或是Maven這一類的構建系統。正如我們在Reloading Java Classes 301 所做的討論那樣，可以透過使用展開式的開發和增量的IDE構建來儘量減少花銷，不過對於大型的應用來說，這種做法通常不是一個可行的選擇。

為了解決這一問題，在JRebel 2.x中，我們為使用者開發了一種方式來把歸檔的應用和模組對映回到工作區中——使用者在每個應用和模組中建立一個rebel.xml配置檔案，該檔案告訴JRebel在哪裡可以找到原始檔。JRebel與應用伺服器整合在一起，當某個類或是資源被更新時，其被從工作區中而不是從歸檔檔案中讀入。

[![workspace-map](https://img-blog.csdnimg.cn/img_convert/0f13760851330156c6ffdb9e7a5e77cf.png)](http://www.hollischuang.com/wp-content/uploads/2015/10/workspace-map.png)

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

這一做法不僅允許類的即時更新，且允許諸如HTML、XML、JSP、CSS、.properties等之類的任何型別的資源的即時更新。Maven使用者甚至不需要建立一個rebel.xml檔案，因為Maven外掛會自動地生成該檔案。

### 除了類過載之外——還有配置和後設資料

在消除週轉期的這一過程中，另一個問題變得明顯起來：現如今的應用已不僅僅是類和資源，它們還透過大量的配置和後設資料繫結在一起。當配置發生改變時，改變應該被反映到那個正在執行的應用上。然而，僅把對配置檔案的修改變成是可見的是不夠的，具體的框架必須要要過載配置，把改變反映到應用中才行。

[![conf](https://img-blog.csdnimg.cn/img_convert/9e2a26530266449f8c7712e701ef0698.png)](http://www.hollischuang.com/wp-content/uploads/2015/10/conf.png)

![](data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== "點選並拖拽以移動")

為了在JRebel中支援這些型別的改變，我們開發了一個開源的API ，該API允許我們的團隊和第三方的捐獻者使用框架特有的外掛來使用JRebel的功能特性，把配置中所做的改變傳播到框架中。例如，我們支援動態實時地在Spring中新增bean和依賴，以及支援在其他框架中所做的各種各樣的改變。

### 結論

本文總結了在未使用動態類載入器情況下的各種過載Java類的方法。我們還討論了導致HotSwap侷限性的原因，揭示了JRebel幕後的工作方式，以及討論了在解決類過載問題時出現的其他問題。

原文地址：http://article.yeeyan.org/view/213582/186226

</variables.size></localvariablenode>

從Java的類載入機制談起：聊聊Java中如何實現熱部署（熱載入）

相關文章