前言

在前阐明：良久没有更新博客了，这一年在公司做了好多事件，包含代码剖析和热部署替换等黑科技，始终没有工夫来进行落地写出一些一文章来，甚是惋惜，趁着中午睡觉的工夫补一篇介绍性的文章吧。

首先热部署的场景是这样的，公司的我的项目十分多，真个BU事业部的我的项目加起来大概上几百个我的项目了，有一些我的项目本地无奈失常启动，所以一些同学在批改完代码，或者是在一般的惯例工作开发过程中都是盲改，而后去公司的代码平台进行公布，恶心的事件就在这里，有的一些我的项目从构建到公布运行大概30分钟，所以每次批改代码到代码奏效须要30分钟的周期，这个极大的升高了公司的开发效率，一旦惰性成习惯，扭转起来将非常的艰难，所以咱们极须要一个在本地批改完代码之后，能够秒级在服务端失效的神器，这样，咱们的热部署插件就诞生了。

热部署在业界自身就是一个难啃的骨头，属于逆向编程的领域，JVM有类加载，那么热部署就要远程桌面去做卸载后从新加载，Spring有上下文注册，spring Bean执行初始化生命周期，热部署就要去做类的销毁，从新初始化，外面设计到的细节点十分之多，业界的几款热部署的解决形式也不尽相同，因为须要微小的底层细节须要解决，所以目前上想找到一个齐全笼罩所有性能的热部署插件是简直不可能的，个别大家听到的热部署插件次要是国外的一些我的项目比方商业版本的jrebel，开源版的springloaded，以及比拟粗犷的spring dev tools。以后这些我的项目都是现成的简单开源我的项目或者是闭包的商业我的项目，想去自行批改匹配本人公司的我的项目，难度是十分之大。闲话少说，进入注释

前言一：什么是热部署

所谓热部署，就是在利用正在运行的时候降级软件，却不须要重新启动利用。对于Java应用程序来说，热部署就是在运行时更新Java类文件，同时触发spring的一些列从新加载过程。在这个过程中不须要重新启动，并且批改的代码实时失效

前言二：为什么咱们须要热部署

程序员每天本地重启服务5-12次，单次大略3-8分钟，每天向Cargo部署3-5次，单次时长20-45分钟，部署频繁频次高、耗时长。插件提供的本地和近程热部署性能可让将代码变更秒级失效，RD日常工作次要分为开发自测和联调两个场景，上面别离介绍热部署在每个场景中施展的作用：

前言三：热部署难在哪，为什么业界没有好用的开源工具

热部署不等同于热重启，像tomcat或者spring boot tool dev这种热重启相当于间接加载我的项目，性能较差，增量文件热部署难度很大，须要兼容各种中间件和用户写法，技术门槛高，须要对JPDA（Java Platform Debugger Architecture）、java agent、字节码加强、classloader、spring框架、Mybatis框架等集成解决方案等各种技术原理深刻理解能力全面反对各种框架，另外须要IDEA插件开发能力，造成整体的产品解决方案。当初有了热部署,代码就是任人装扮的小姑娘!

前言四：为什么咱们不必spring boot devtools

有一些敌人问我，为什么不间接应用spring boot devtools，有两方面起因吧，第一它仅仅只应用在spring boot我的项目中，对于一般的java我的项目以及spring xml我的项目是不反对的，最次要的第二点它的热加载计划实际上和tomcat热加载是一样的，只不过它的热加载通过嵌套classloader的形式来实现，这个classloader每次只加载class file变更的class二进制文件，这样就会来带一个问题，在十分宏大的我的项目背后（启动大概10min+）这种状况，它就显得很红润。这归根结底的起因是在于他的reload范畴切实是太大了，对于一些小我的项目还能够，然而一些比拟宏大的我的项目理论应用成果还是十分感人的。

1、整体设计方案

2.1、JVM启动前动态Instrument

Javaagent是java命令的一个参数。参数 javaagent 能够用于指定一个 jar 包，并且对该 java 包有2个要求：

这个 jar 包的 MANIFEST.MF 文件必须指定 Premain-Class 项。

Premain-Class 指定的那个类必须实现 premain() 办法。

premain 办法，从字面上了解，就是运行在 main 函数之前的的类。当Java 虚拟机启动时，在执行 main 函数之前，JVM 会先运行-javaagent所指定 jar 包内 Premain-Class 这个类的 premain 办法 。

2.3、instrument原理：

instrument的底层实现依赖于JVMTI(JVM Tool Interface)，它是JVM裸露进去的一些供用户扩大的接口汇合，JVMTI是基于事件驱动的，JVM每执行到肯定的逻辑就会调用一些事件的回调接口（如果有的话），这些接口能够供开发者去扩大本人的逻辑。JVMTIAgent是一个利用JVMTI裸露进去的接口提供了代理启动时加载(agent on load)、代理通过attach模式加载(agent on attach)和代理卸载(agent on unload)性能的动静库。而instrument agent能够了解为一类JVMTIAgent动静库，别名是JPLISAgent(Java Programming Language Instrumentation Services Agent)，也就是专门为java语言编写的插桩服务提供反对的代理。

2.3.1、启动时加载instrument agent过程：

创立并初始化 JPLISAgent；

监听 VMInit 事件，在 JVM 初始化实现之后做上面的事件：

创立 InstrumentationImpl 对象 ；

监听 ClassFileLoadHook 事件 ；

调用 InstrumentationImpl 的loadClassAndCallPremain办法，在这个办法里会去调用 javaagent 中 MANIFEST.MF 里指定的Premain-Class 类的 premain 办法 ；

解析 javaagent 中 MANIFEST.MF 文件的参数，并依据这些参数来设置 JPLISAgent 里的一些内容。

2.3.2、运行时加载instrument agent过程：

通过 JVM 的attach机制来申请指标 JVM 加载对应的agent，过程大抵如下：

创立并初始化JPLISAgent；

解析 javaagent 里 MANIFEST.MF 里的参数；

创立 InstrumentationImpl 对象；

监听 ClassFileLoadHook 事件；

调用 InstrumentationImpl 的loadClassAndCallAgentmain办法，在这个办法里会去调用javaagent里 MANIFEST.MF 里指定的Agent-Class类的agentmain办法。

2.3.3、Instrumentation的局限性

大多数状况下，咱们应用Instrumentation都是应用其字节码插桩的性能，或者抽象说就是类重定义(Class Redefine)的性能，然而有以下的局限性：

premain和agentmain两种形式批改字节码的机会都是类文件加载之后，也就是说必须要带有Class类型的参数，不能通过字节码文件和自定义的类名从新定义一个原本不存在的类。

类的字节码批改称为类转换(Class Transform)，类转换其实最终都回归到类重定义Instrumentation#redefineClasses()办法，此办法有以下限度：

新类和老类的父类必须雷同；

新类和老类实现的接口数也要雷同，并且是雷同的接口；

新类和老类拜访符必须统一。 新类和老类字段数和字段名要统一；

新类和老类新增或删除的办法必须是private static/final润饰的；

能够批改办法体。

除了下面的形式，如果想要从新定义一个类，能够思考基于类加载器隔离的形式：创立一个新的自定义类加载器去通过新的字节码去定义一个全新的类，不过也存在只能通过反射调用该全新类的局限性。

2.4、那些年JVM和Hotswap之间的相爱相杀

围绕着method body的hotSwap JVM始终在进行改良

1.4开始JPDA引入了hotSwap机制（JPDA Enhancements），实现了debug时的method body的动态性1.5开始通过JVMTI实现的java.lang.instrument (Java Platform SE 8 ) 的premain形式，实现了agent形式的动态性（JVM启动时指定agent）1.6又减少了agentmain形式，实现了运行时动态性（通过The Attach API 绑定到具体VM）。其根本实现是通过JVMTI的retransformClass/redefineClass进行method body级的字节码更新，ASM、CGLib之类根本都是围绕这些在做动态性。

然而针对Class的hotSwap始终没有动作（比方Class增加method，增加field，批改继承关系等等），为什么？因为复杂度高并且没有太高的回报。

2.5、如何解决Instrumentation的局限性

因为JVM限度，JDK7和JDK8都不容许都改类构造，比方新增字段，新增办法和批改类的父类等，这对于spring我的项目来说是致命的，假如小龚同学想批改一个spring bean，新增了一个@Autowired字段，这种场景在理论利用时很多，所以咱们对这种场景的反对必不可少。

那么咱们是如何做到的呢，上面有请赫赫有名的dcevm，dcevm(DynamicCode Evolution Virtual Machine)是java hostspot的补丁(严格上来说是批改),容许(并非无限度)在运行环境下批改加载的类文件.以后虚拟机只容许批改办法体(method bodies),decvm,能够减少 删除类属性、办法

3、热部署技术解析

3.1、文件监听

热部署启动时首先会在本地和近程预约义两个目录，/var/tmp/xxx/extraClasspath和/var/tmp/xxx/classes，extraClasspath为咱们自定义的拓展classpath url,classes为咱们监听的目录，当有文件变更时，通过idea插件来部署到近程/本地，触发agent的监听目录，来持续上面的热加载逻辑，为什么咱们不间接替换用户的classPath上面的资源文件呢，因为业务方思考到war包的api我的项目，和spring boot我的项目，都是以jar包来启动的，这样咱们是无奈间接批改用户的class文件的，即便是用户我的项目咱们能够批改，间接操作用户的class，也会带来一系列的平安问题，所以咱们采纳了拓展classPath url来实现文件的批改和新增，并且有这么一个场景，多个业务侧的我的项目引入了雷同的jar包，在jar外面配置了mybatis的xml和注解，这种状况咱们没有方法间接来批改jar包中源文件，通过拓展门路的形式能够不须要关注jar包来批改jar包中某一文件和xml，是不是很炫酷，同理这种办法能够进行整个jar包的热替换(方案设计中)。上面简略介绍一下外围监听器

3.2、jvm class reload

JVM的字节码批量重载逻辑，通过新的字节码二进制流和旧的class对象生成ClassDefinition定义，instrumentation.redefineClasses(definitions)，来触发JVM重载，重载过后将触发初始化时spring插件注册的transfrom，下一章咱们简略解说一下spring是怎么重载的。

新增class咱们如何保障能够加载到classloader上下文中？因为我的项目在近程执行，所以运行环境简单，有可能是jar包形式启动(spring boot)，也有可能是一般我的项目，也有可能是war web我的项目，针对这种状况咱们做了一层classloader url拓展User classLoader是框架自定义的classLoader统称，例如Jetty我的项目是WebAppclassLoader，其中Urlclasspath为以后我的项目的lib文件件下，例如spring boot我的项目也是从以后我的项目中BOOT-INF/lib/，等等，不同框架的自定义地位稍有不同。所以针对这种状况 咱们必须拿到用户的自定义classloader，如果惯例形式启动的，比方一般spring xml我的项目借助plus公布，这种没有自定义classloader，是默认AppClassLoader，所以咱们在用户我的项目启动过程中借助agent字节码加强的形式来获取到真正的用户classloader。

咱们做的事件：找到用户应用的子classloader之后通过反射的形式来获取classloader中的元素Classpath,其中classPath中的URL就是以后我的项目加载class时须要的所有运行时class环境，并且包含三方的jar包依赖等。

咱们获取到URL数组，把咱们自定义的拓展classpath目录退出到URL数组的首位，这样当有新增class时，咱们只须要将class文件放到拓展classpath对应的包目录上面即可，当有其余bean依赖新增的class时，会从当前目录上面查找类文件。

为什么不间接对Appclassloader进行增强？而是对框架的自定义classloader进行增强思考这样一个场景，框架自定义类加载器中有ClassA，而后这个时候用户新增了一个Class B须要热加载，B class外面有A的援用关系,如果咱们加强AppClassLoader时，初始化B实例时ClassLoader.loadclass首先从UserClassLoader开始找classB，依附双亲委派准则，B是被Appclassloader加载的，因为B依赖了类A，所以以后AppClassLoader加载B肯定是找不到的，这个时候汇报ClassNotFoundException。也就是说咱们对类加载器拓展肯定要拓展最上层的类加载器，这样才会达到咱们想要的成果。

3.3、spring bean重载

spring bean reload过程中，bean的销毁和重启流程，其中细节点波及的比拟多。首先当批改java class D时，通过spring classpathScan扫描校验以后批改的bean是否是spring bean（注解校验）而后触发销毁流程（BeanDefinitionRegistry.removeBeanDefinition）此办法会将以后spring 上下文中的 bean D 和依赖 spring bean D的 Bean C 一并销毁，然而作用范畴仅仅在以后spring 上下文，若C被子上下文中的Bean B 依赖，是无奈更新子上下文中的依赖关系的，此时，当有流量打进来，Bean B中关联的Bean C还是热部署之前的对象，所以热部署失败，所以咱们在spring初始化过程中，须要保护一个父子上下文的对应关系，当子上下文变时若变更范畴波及到Bean B时，须要从新更新子上下文中的依赖关系，所以当有多上下文关联时须要保护多上下文环境，并且以后上下文环境入口须要reload。入口指：spring mvc controller，Mthrift和pigeon，对不同的流量入口，咱们采纳不同的reload策略。RPC框架入口次要操作为解绑注册核心，从新注册，从新加载启动流程等，对Spring mvc controller次要是解绑和注册url Mappping来实现流量入口类的变动切换

3.4、spring xml重载

当用户批改/新增spring xml时，须要对xml中所有bean进行重载

从新reload之后，将spring 销毁后重启。

留神:xml批改形式改变较大，可能波及到全局的Aop的配置以及前置和后置处理器相干的内容，影响范畴为全局，所以目前只放开一般的xml bean标签的新增/批改，其余能力酌情逐渐放开。