JVM之熱部署hotswap
熱部署是在不重啟 Java 虛擬機器的前提下，能自動偵測到 class 檔案的變化，更新執行時 class 的行為。
目前的 Java 虛擬機器只能實現方法體的修改熱部署，對於整個類的結構修改，仍然需要重啟虛擬機器，對類重新載入才能完成更新操作。對於某些大型的應用來說，每次的重啟都需 要花費大量的時間成本。雖然 osgi 架構的出現，讓模組重啟成為可能，但是如果模組之間有呼叫關係的話，這樣的操作依然會讓應用出現短暫的功能性休克。本文將探索如何在不破壞 Java 虛擬機器現有行為的前提下，實現某個單一類的熱部署，讓系統無需重啟就完成某個類的更新。
預設的虛擬機器行為只會在啟動時載入類，如果後期有一個類需要更新的話，單純替換編譯的 class 檔案，Java 虛擬機器是不會更新正在執行的 class。如果要實現熱部署，最根本的方式是修改虛擬機器的原始碼
另 一種友好的方法是建立自己的 classloader 來載入需要監聽的 class（終極方案），這樣就能控制類載入的時機，從而實現熱部署。
難點：
這種自上而下（父類優先載入）的載入方式的好處是，讓每個 classloader 執行自己的載入任務，不會重複載入類。但是這種方式卻使載入順序非常難改變，讓自定義 classloader 搶先載入需要監聽改變的類成為了一個難題。
不過我們可以換一個思路，雖然無法搶先載入該類，但是仍然可以用自定義 classloader 建立一個功能相同的類，讓每次例項化的物件都指向這個新的類。當這個類的 class 檔案發生改變的時候，再次建立一個更新的類，之後如果系統再次發出例項化請求，建立的物件講指向這個全新的類。
實現：
下面來簡單列舉一下需要做的工作。
- 建立自定義的 classloader，載入需要監聽改變的類，在 class 檔案發生改變的時候，重新載入該類。
- 改變建立物件的行為，使他們在建立時使用自定義 classloader 載入的 class。
利用 ASM 修改 class 檔案
可 以修改位元組碼的框架有很多，比如 ASM，CGLIB。本文使用的是 ASM。先來介紹一下 class 檔案的結構，class 檔案包含了以下幾類資訊，一個是類的基本資訊，包含了訪問許可權資訊，類名資訊，父類資訊，介面資訊。第二個是類的變數資訊。第三個是方法的資訊。ASM 會先載入一個 class 檔案，然後嚴格順序讀取類的各項資訊，使用者可以按照自己的意願定義增強元件修改這些資訊，最後輸出成一個新的 class。
首先看一下如何利用 ASM 修改類資訊。
清單 1. 利用 ASM 修改位元組碼
| 1234567891011121314 | ClassWriter cw = new ClassWriter(ClassWriter.<em>COMPUTE_MAXS</em>);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); |
ASM 修改位元組碼檔案的流程是一個責任鏈模式，首先使用一個 ClassReader 讀入位元組碼，然後利用 ClassVisitor 做個性化的修改，最後利用 ClassWriter 輸出修改後的位元組碼。
之前提過，需要將讀取的 class 檔案的類名做一些修改，載入成一個全新名字的派生類。這裡將之分為了 2 個步驟。
第一步，先將原來的類變成介面。
清單 2. 重定義的原始類
| 123456789101112131415161718 | public Class<?> redefineClass(String className){ClassWriter cw = new ClassWriter(ClassWriter.<em>COMPUTE_MAXS</em>);ClassReader cr = null;ClassSource cs = <em>classFiles</em>.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);} |
首先 load 原始類的 class 檔案，此處定義了一個增強元件 ClassModifier，作用是修改原始類的型別，將它轉換成介面。原始類的所有方法邏輯都會被去掉。
第二步，生成的派生類都實現這個介面，即原始類，並且複製原始類中的所有方法邏輯。之後如果該類需要更新，會生成一個新的派生類，也會實現這個介面。這樣做的目的是不論如何修改，同一個 class 的派生類都有一個共同的介面，他們之間的轉換變得對外不透明。
清單 3. 定義一個派生類
| 123456789101112131415161718192021222324 | // 在 class 檔案發生改變時重新定義這個類private Class<?> redefineClass(String className, ClassSource classSource){ClassWriter cw = new ClassWriter(ClassWriter.<em>COMPUTE_MAXS</em>);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;} |
再次 load 原始類的 class 檔案，此處定義了兩個增強元件，一個是 EnhancedModifier，這個增強元件的作用是改變原有的類名。第二個增強元件是 ExtendModifier，這個增強元件的作用是改變原有類的父類，讓這個修改後的派生類能夠實現同一個原始類（此時原始類已經轉成介面了）。
自定義 classloader 還有一個作用是監聽會發生改變的 class 檔案，classloader 會管理一個定時器，定時依次掃描這些 class 檔案是否改變。
改變建立物件的行為
Java 虛擬機器常見的建立物件的方法有兩種，一種是靜態建立，直接 new 一個物件，一種是動態建立，通過反射的方法，建立物件。
由於已經在自定義載入器中更改了原有類的型別，把它從類改成了介面，所以這兩種建立方法都無法成立。我們要做的是將例項化原始類的行為變成例項化派生類。
對於第一種方法，需要做的是將靜態建立，變為通過 classloader 獲取 class，然後動態建立該物件。
清單 4. 替換後的指令集所對應的邏輯
| 12345 | // 原始邏輯 Greeter p = new Greeter();// 改變後的邏輯IGreeter p = (IGreeter)MyClassLoader.<em>getInstance</em>().findClass("com.example.Greeter").newInstance(); |
這裡又需要用到 ASM 來修改 class 檔案了。查詢到所有 new 物件的語句，替換成通過 classloader 的形式來獲取物件的形式。
清單 5. 利用 ASM 修改方法體
| 1234567891011121314151617181920212223242526 | @Overridepublic void visitTypeInsn(int opcode, String type) {if(opcode==Opcodes.<em>NEW</em> && type.equals(className)){List<LocalVariableNode> variables = node.localVariables;String compileType = null;for(int i=0;i<variables.size();i++){LocalVariableNode localVariable = variables.get(i);compileType = <em>formType</em>(localVariable.desc);if(matchType(compileType)&&!valiableIndexUsed[i]){valiableIndexUsed[i] = true;break;}}mv.visitMethodInsn(Opcodes.<em>INVOKESTATIC</em>, <em>CLASSLOAD_TYPE</em>,"getInstance", "()L"+<em>CLASSLOAD_TYPE</em>+";");mv.visitLdcInsn(type.replace("/", "."));mv.visitMethodInsn(Opcodes.<em>INVOKEVIRTUAL</em>, <em>CLASSLOAD_TYPE</em>,"findClass", "(Ljava/lang/String;)Ljava/lang/Class;");mv.visitMethodInsn(Opcodes.<em>INVOKEVIRTUAL</em>, "java/lang/Class","newInstance", "()Ljava/lang/Object;");mv.visitTypeInsn(Opcodes.<em>CHECKCAST</em>, compileType);flag = true;} else {mv.visitTypeInsn(opcode, type);}} |
對於第二種建立方法，需要通過修改 Class.forName()和 ClassLoader.findClass()的行為，使他們通過自定義載入器載入類。
使用 JavaAgent 攔截預設載入器的行為
之 前實現的類載入器已經解決了熱部署所需要的功能，可是 JVM 啟動時，並不會用自定義的載入器載入 classpath 下的所有 class 檔案，取而代之的是通過應用載入器去載入。如果在其之後用自定義載入器重新載入已經載入的 class，有可能會出現 LinkageError 的 exception。所以必須在應用啟動之前，重新替換已經載入的 class。如果在 jdk1.4 之前，能使用的方法只有一種，改變 jdk 中 classloader 的載入行為，使它指向自定義載入器的載入行為。好在 jdk5.0 之後，我們有了另一種侵略性更小的辦法，這就是 JavaAgent 方法，JavaAgent 可以在 JVM 啟動之後，應用啟動之前的短暫間隙，提供空間給使用者做一些特殊行為。比較常見的應用，是利用 JavaAgent 做面向方面的程式設計，在方法間加入監控日誌等。
JavaAgent 的實現很容易，只要在一個類裡面，定義一個 premain 的方法。
清單 6. 一個簡單的 JavaAgent
| 123456 | public class ReloadAgent {public static void premain(String agentArgs, Instrumentation inst){GeneralTransformer trans = new GeneralTransformer();inst.addTransformer(trans);}} |
然後編寫一個 manifest 檔案，將 Premain-Class屬性設定成定義一個擁有 premain方法的類名即可。
生成一個包含這個 manifest 檔案的 jar 包。
| 123 | manifest-Version: 1.0Premain-Class: com.example.ReloadAgentCan-Redefine-Classes: true |
最後需要在執行應用的引數中增加 -javaagent引數 , 加入這個 jar。同時可以為 Javaagent增加引數，下圖中的引數是測試程式碼中 test project 的絕對路徑。這樣在執行應用的之前，會優先執行 premain方法中的邏輯，並且預解析需要載入的 class。
圖 1. 增加執行引數
這裡利用 JavaAgent替換原始位元組碼，阻止原始位元組碼被 Java 虛擬機器載入。只需要實現 一個 ClassFileTransformer的介面，利用這個實現類完成 class 替換的功能。
清單 7. 替換 class
| 12345678910111213141516 | @Overridepublic byte [] transform(ClassLoader paramClassLoader, String paramString,Class<?> paramClass, ProtectionDomain paramProtectionDomain,byte [] paramArrayOfByte) throws IllegalClassFormatException {String className = paramString.replace("/", ".");if(className.equals("com.example.Test")){MyClassLoader cl = MyClassLoader.<em>getInstance</em>();cl.defineReference(className, "com.example.Greeter");return cl.getByteCode(className);}else if(className.equals("com.example.Greeter")){MyClassLoader cl = MyClassLoader.<em>getInstance</em>();cl.redefineClass(className);return cl.getByteCode(className);}return null;} |
至此，所有的工作大功告成，欣賞一下 hotswap 的結果吧。
圖 2. Test 執行結果
結束語
解 決 hotswap 是個困難的課題，本文解決的僅僅是讓新例項化的物件使用新的邏輯，並不能改變已經例項化物件的行為，如果 JVM 能夠重新設計 class 的生命週期，支援執行時重新更新一個 class，hotswap 就會成為 Java 的一個閃亮新特性。官方的 JVM 一直沒有解決熱部署這個問題，可能也是由於無法完全克服其中的諸多難點，希望未來的 Jdk 能解決這個問題，讓 Java 應用對於更新更友好，避免不斷重啟應用浪費的時間。