JRebel支持三方插件较多，生态庞大，但是对于国产的插件不支持，例如FastJson等，同时它还存在远程热部署配置局限，对于公司内部的中间件需要个性化开发，并且是商业软件，整体的使用成本较高。

挑战：
1 旧字节码替换为新的字节码
2 旧对象替换为新对象
3 第三方注入依赖：如spring；mybatis xml配置；yaml配置

主流解决方案：
1 JRebel：目前最常用的热部署工具，是一款收费的商业软件，因此在稳定性和兼容性上做的都比较好，基于DCE VM。
2 Spring-Loaded：Spring 子项目，也是一款开源的热部署工具。基于java -aggent。
3 Hotcode2：阿里内部开发和使用的热部署工具，针对各种框架做了很多适配。基于多层代理。
4 spring-boot-devtools部署：依赖重启。
5 osgi sofa-ark：类隔离架构。
6 美团Sonic 基于DCE VM。

0 JVM和HotSwap之间的“相爱相杀”

围绕着Method Body的HotSwap JVM一直在进行改进。从1.4版本开始，JPDA引入HotSwap机制（JPDA Enhancements），实现Debug时的Method Body的动态性。大家可参考文档：enhancements1.4。
1.5版本开始通过JVMTI实现的java.lang.instrument（Java Platform SE 8）的Premain方式，实现Agent方式的动态性（JVM启动时指定Agent）。大家可参考文档：package-summary。
1.6版本又增加Agentmain方式，实现运行时动态性（通过The Attach API 绑定到具体VM）。大家可参考文档：package-summary 。基本实现是通过JVMTI的retransformClass/redefineClass进行method、body级的字节码更新，ASM、CGLib基本都是围绕这些在做动态性。
但是针对Class的HotSwap一直没有动作（比如Class添加method、添加field、修改继承关系等等），为什么会这样呢？因为复杂度过高，且没有很高的回报。

通过新的字节码二进制流和旧的Class对象生成ClassDefinition定义，instrumentation.redefineClasses（definitions），来触发JVM重载，重载过后将触发初始化时Spring插件注册的Transfrom

1 IDE提供的HotSwap（基于java agent）

使用eclipse或IntelliJ IDEA通过debug模式启动时，默认会开启一项HotSwap功能。用户可以在IDE里修改代码时，直接替换到目标程序的类里。不过这个功能只允许修改方法体，而不允许对方法进行增删改。
该功能的实现与debug有关。debug其实也是通过JVMTI agent来实现的，JVITI agent会在debug连接时加载到debugee的JVM中。debuger（IDE）通过JDI（Java debug interface）与debugee（目标Java程序）通过进程通讯来设置断点、获取调试信息。除了这些debug的功能之外，JDI还有一项redefineClass的方法，可以直接修改一个类的字节码。没错，它其实就是暴露了JVMTI的bytecode instrument功能，而IDE作为debugger，也顺带实现了这种HotSwap功能。
原理示意图如下，顺带着也把Java debug的原理也画了出来，毕竟知识都是相通的

2 Tomcat的自动reload

Tomcat在配置Context（对应一个web应用，一个host下可以有多个context）时，有一个属性reloadable，当设置为true时，会监听其classpath下的类文件变动情况，当它有变动时，会自动重启所在的web应用（context）。
这里的重启，会先停止掉当前的Context，然后重新解析一遍xml，重新创建Webappclassloader，重新加载类。Tomcat的类加载机制分配给每个Context一个独立的类加载器，这样一来类的重新加载就成为了可能————直接使用新的类加载器重新加载一遍，避免了同一个类加载器不能重复加载一个类的限制。
把Tomcat的reload机制分类到热部署里的确有些牵强，我认为应该算作增量部署吧。不过这也算是热部署的实现思路之一，通过新的classloader重新全部加载一遍。缺陷也很明显：程序的状态可能丢失，耗时可能很长，而且如果应用只配置了一个Context那就和重启整个Tomcat没有太大差别了

3 JRebel,spring-loaded,hotcode2等热部署工具

说到热部署，这些工具应该算得上最适合使用的了，这些热部署工具“突破”了只能修改方法体的JVM客观限制，实现了很多额外的功能例如增删改方法签名、增删改成员变量等等，尽最大可能让代码能够自由自在的热部署。目前了解到比较常见的有以下几种：

JRebel：目前最常用的热部署工具，是一款收费的商业软件，因此在稳定性和兼容性上做的都比较好，基于DCE VM。
Spring-Loaded：Spring旗下的子项目，也是一款开源的热部署工具。

Hotcode2：阿里内部开发和使用的热部署工具，功能和上面基本一样，基于剁成代理，同时针对各种框架做了很多适配。

spring-boot-devtools部署：依赖重启<br />首先都是通过**Java agent，使用Instumentation API来修改已加载的类**。既然Instumentation只能修改方法体，为什么这些工具突破了这个限制呢？实际上，**这些工具在每个method call和field access的地方都做了一层代理**，对于每次修改类，并不是直接**retransformClasses，而是直接加载一个全新的类**，由于方法调用和成员变量读写都被动态代理过，新修改的类自然能够成功“篡位”了。

举一个JRebel的简化版的例子，假设一个类一开始长这样

public class C extends X {
int y = 5;
int method1(int x) {
 return x + y;
}
void method2(String s) {
 System.out.println(s);
}
}

那么这个类在加载时，就会被JRebel的agent转换掉：每个方法的方法体都变成了代理，其内容变成了调用某个具体实现类的同名方法。

public class C extends X {
int y = 5;
int method1(int x) {// 什么也不做，只把参数和方法名传递给名叫Runtime的代理
 Object[] o = new Object[1];
 o[0] = x;
 return Runtime.redirect(this, o, "C", "method1", "(I)I");
}
void method2(String s) {
 Object[] o = new Object[1];
 o[0] = s;
 return Runtime.redirect(this, o, "C", "method2", "(Ljava/lang/String;)V");
}
}

原代码的实现逻辑当然也不会丢掉，而是通过加载一个名叫C0的新类作为实现类。刚才通过Runtime.redirect的调用，会被路由到这个实现类的对应方法里。如果此时用户再次更新了类C的代码，那么会再重新加载一个C1类，然后C2,C3,C4,C5…

public abstract class C0 {
 public static int method1(C c, int x) {
   int tmp1 = Runtime.getFieldValue(c, "C", "y", "I");
   return x + tmp1;
 }
 public static void method2(C c, String s) {
   PrintStream tmp1 =
     Runtime.getFieldValue(
       null, "java/lang/System", "out", "Ljava/io/PrintStream;");
   Object[] o = new Object[1];
   o[0] = s;
   Runtime.redirect(tmp1, o, "java/io/PrintStream;", "println","(Ljava/lang/String;)V");
 }
}

通过这种方式，就可以在JVM既定的限制下，完成更自由的热部署。当然这种热部署行为，是需要做很多细节的兼容的，例如反射的各个方法都要做一些特殊的兼容处理，还有异常栈的获取不能真的把这些代理类透传出去……另外，由于很多类的行为是通过框架初始化的时候进行的，这些热部署工具还要对一些框架深度加工，来完成xml和注解的自动初始化，比如spring的配置xml、mybatis的sqlmap等

4 Dynamic Code Evolution VM (DCE VM)

DCEVM是一款基于Java HotSpot(TM) VM修改的JVM，其目的就是允许对加载过的类无限制的修改（redefinition）。从技术的角度来讲，通过VM的修改实现热部署是最合理也是性能最好的方案

5 OSGi的热部署

以服务形式发布，3个挑战都没了。

http://www.fanyilun.me/2017/07/18/%E8%B0%88%E8%B0%88Java%20Intrumentation%E5%92%8C%E7%9B%B8%E5%85%B3%E5%BA%94%E7%94%A8/

Java 基础 & 线上问题分析