看看热部署和热加载

一、热部署和热加载

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

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

区别：

热加载：服务器会监听 class 文件改变，包括web-inf/class,wen-inf/lib,web-inf/web.xml等文件，若发生更改，则局部进行加载，不清空session ，不释放内存。开发中用的多，但是要考虑内存溢出的情况。

热部署： 整个项目从新部署，包括你从新打上 .war 文件。 会清空session ，释放内存。项目打包的时候用的多。

二、实现原理

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

对比反射机制，反射是在运行时获取类信息，通过动态的调用来改变程序行为；

热加载则是在运行时通过重新加载改变类信息，直接改变程序行为。

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

三、在java中应用

1.生产环境

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

• 一、安全性

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

• 二、适用的情景

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

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

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

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

2.开发环境

在生产中，不会有频繁的部署并且启动耗时长的应用，但由于云计算的兴起，热部署还是有其应用。

而热加载有点玩火，太危险了。但在开发和debug中，频繁启动应用却随处可见，热加载机制可以极大的提升开发效率。这两种机制，在开发中还有另外一种称呼—开发者模式。

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

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

总结

在实际生产中热部署在云计算中运用挺多，但热加载没有，而在开发中，热加载可以显著的提升工作效率，强烈推荐使用热加载方式，不仅tomcat，大多数其他servlet容器也支持这种方式，大家可以自行搜索相关技巧。