java的热部署和热加载

ps:热部署和热加载其实是两个类似但不同的概念，之前理解不深，so，这篇文章重构了下。

一、热部署与热加载

在应用运行的时升级软件，无需重新启动的方式有两种，热部署和热加载。

对于Java应用程序来说，热部署就是在服务器运行时重新部署项目，热加载即在在运行时重新加载class，从而升级应用。

二、实现原理

热加载的实现原理主要依赖java的类加载机制，在实现方式可以概括为在容器启动的时候起一条后台线程，定时的检测类文件的时间戳变化，如果类的时间戳变掉了，则将类重新载入。

对比反射机制，反射是在运行时获取类信息，通过动态的调用来改变程序行为；
热加载则是在运行时通过重新加载改变类信息，直接改变程序行为。

热部署原理类似，但它是直接重新加载整个应用，这种方式会释放内存，比热加载更加干净彻底，但同时也更费时间。

三、在java中应用

1.生产环境

热部署作为一个比较灵活的机制，在实际的生产上运用还是有，但相对很少，热加载则基本没有应用。分析如下

一、安全性

热加载这种直接修改jvm中字节码的方式是难以监控的，不同于sql等执行可以记录日志，直接字节码的修改几乎无法记录代码逻辑的变化，对既有代码行为的影响难以控制，对于越注重安全的应用，热加载带来的风险越大,这好比给飞行中的飞机更换发动机。

二、适用的情景

技术大部分是跟需求挂钩的，而需要热部署的情景很少。

频繁的部署并且启动耗时长的应用
无法停止服务的应用

在生产中，并没有需要频繁部署的应用，即使是敏捷，再快也是一周一次的迭代，并且通过业务划分和模块化编程，部署的代价完全可以忽略不计，对于现有的应用，启动耗时再长，也并非长到无法忍受，如果真的这么长，那更应该考虑的是如何进行模块拆分，分布式部署了。

对于无法停止服务的应用，比如现在的云计算平台这样分布式应用，采用分批上线也可以满足需求，类似热部署方案应该是放在最后考虑的解决方案。

2.开发环境

在生产中，不会有频繁的部署并且启动耗时长的应用，但由于云计算的兴起，热部署还是有其应用。
而热加载有点玩火，太危险了。但在开发和debug中，频繁启动应用却随处可见，热加载机制可以极大的提升开发效率。这两种机制，在开发中还有另外一种称呼—开发者模式。

对于大型项目：往往启/停需要等待几分钟时间。更浪费时间的是，对于一个类中的方法的调试过程，如果修改多次，需要反复的启停服务器，浪费的时间更多。

以目前的crm项目为例，其启动时间为5m，以一天debug重启十次，一个月工作20天来算，每年重启耗时25人日，如果能完全使用热加载，每年节省重启时间近1人月。

crm pool启动耗时

1.struts2热加载

在struts2中热加载即开发者模式，在struts.xml配置

<constant name="struts.devMode" value="true" />

从而当更改struts.xml文件后不需要重新启动服务器就可以进行程序调试。

2.开发时使用tomcat热加载

tomcat本身默认开启了热部署方式，但热部署是直接重新加载整个应用，耗时跟重启服务器差不多，我们需要的其实是热加载，即修改了哪个class，只重新加载这一个class，这样耗时几乎为0。
对于tomcat5.x 以上版本，均已支持一定程度上得热加载，但这种方式只针对代码行级别的，也就是说如果新删方法，注解，类，或者变量时是无效的，只能重启，这是我目前在公司开发时用的方式，可以显著降低debug时的重启次数，提高开发效率

1.将tomcat server.xml文件的context reloadable 值置为false 或者在web modules中编辑取消Auto reloading选项。