程序员留的后门，怎么能管它叫热部署呢？

前言

这篇文章给大家分享一个热部署相关的知识点。

这可是一个好东西啊，当年在学习学 JSP 的时候，哐哐哐一顿操作，发现服务没重启，我在 JSP 里面写的东西就直接生效了。

当场我就是一个大大的震惊，而旁边教我的人只是说着一些什么热部署，字节码，classloader 重写之类的我根本就听不懂的话。

但是听不懂不重要，我会使用就行了。随即就是一顿疯狂练习，把这玩意用的炉火纯青，什么 pageContext 上下文，redirect 重定向,forward 转发，九大内置对象，完整的生命周期啥的，手到擒来。

可惜这玩意不争气，在前后端分离的大潮下，自己慢慢的没落了。搞得我空有一身 JSP 本领，无处施展。

后来啊，

后来，我就自己悄悄的在程序里面基于它做了很多后门嘛，但是我发誓，我没有一点点其他的想法，真的是出于好心，出于责任心，想要加快线上问题响应效率，就在里面各种线上骚操作，刀尖跳舞，可好用了...

好了，说回热部署。

首先我们明确下什么叫做热部署，热部署是在不重启 java 虚拟机的前提下，自动更新 class 的行为，从而更新整个运行时的逻辑。

在 java 开发领域，热部署一直是一个难以解决的问题，java 虚拟机理论上只能实现方法体的修改热部署，对于整个类结构的更改，仍然需要重启虚拟机，对类重新加载才能完成更新操作。

OSGI

其实 java 业界有一些解决方案，比如 osgi 架构，这玩意时间比较长了，但一直没火起来。

osgi 架构的出现，可以让 java 系统变成模块化的形式，让模块重启成为可能。从一定程度上也算是个热部署的方案。

可惜这玩意以前开发起来就觉得很反人类，配置文件一大堆不说，学习成本也很大。

和 spring 结合起来，居然是一个模块一个 spring 上下文体系。并且如果模块之间有调用关系的话，重启相关的模块会让应用出现短暂的功能性休克，也就说，整个热启动过程不平滑。

这项技术现在估计很多小伙伴都没听说过，目前也渐渐的退出历史舞台，用的企业估计很少。

ASM

ASM 是一款修改字节码的框架，同类型的框架还有 Cglib。

这些框架能加载一个 class 信息，用户可以按照自己的需求增强修改这些信息，最后输出成一个新的 class。

具体实现过程，这里就不展开了。大家可以搜索下，相关技术实现文章不少。

但单纯修改字节码一般要和其他技术结合起来，单靠这个也无法完成热更新，虽然 ASM 类的框架能够修改类，但是这些 ASM 的修改逻辑也是用 java 写的，这段代码也需要执行的。

如果你把 ASM 的代码写在 java 里，也无法实现从外部来热更新。

Javaagent&Attach API结合ASM