共计 6565 个字符，预计需要花费 17 分钟才能阅读完成。
前言
在前阐明：良久没有更新博客了，这一年在公司做了好多事件，包含代码剖析和热部署替换等黑科技，始终没有工夫来进行落地写出一些一文章来，甚是惋惜，趁着中午睡觉的工夫补一篇介绍性的文章吧。
首先热部署的场景是这样的，公司的我的项目十分多，真个 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 标签的新增 / 批改，其余能力酌情逐渐放开。
