看看热部署和热加载
看看热部署和热加载
一、热部署和热加载
在应用运行的时升级软件，无需重新启动的方式有两种，热部署和热加载。
对于Java应用程序来说，热部署就是在服务器运行时重新部署项目，热加载即在在运行时重新加载class，从而升级应用。
区别：
热加载：服务器会监听 class 文件改变，包括web-inf/class,wen-inf/lib,web-inf/web.xml等文件，若发生更改，则局部进行加载，不清空session ，不释放内存。开发中用的多，但是要考虑内存溢出的情况。
热部署： 整个项目从新部署，包括你从新打上.war 文件。会清空session ，释放内存。项目打包的时候用的多。
二、实现原理
热加载的实现原理主要依赖java的类加载机制，在实现方式可以概括为在容器启动的时候起一条后台线程，定时的检测类文件的时间戳变化，如果类的时间戳变掉了，则将类重新载入。
对比反射机制，反射是在运行时获取类信息，通过动态的调用来改变程序行为；
热加载则是在运行时通过重新加载改变类信息，直接改变程序行为。
热部署原理类似，但它是直接重新加载整个应用，这种方式会释放内存，比热加载更加干净彻底，但同时也更费时间。
三、在java中应用
1.生产环境
热部署作为一个比较灵活的机制，在实际的生产上运用还是有，但相对很少，热加载则基本没有应用。分析如下
- 一、安全性
热加载这种直接修改jvm中字节码的方式是难以监控的，不同于sql等执行可以记录日志，直接字节码的修改几乎无法记录代码逻辑的变化，对既有代码行为的影响难以控制，对于越注重安全的应用，热加载带来的风险越大,这好比给飞行中的飞机更换发动机。
- 二、适用的情景
技术大部分是跟需求挂钩的，而需要热部署的情景很少。
- 频繁的部署并且启动耗时长的应用
- 无法停止服务的应用
在生产中，并没有需要频繁部署的应用，即使是敏捷，再快也是一周一次的迭代，并且通过业务划分和模块化编程，部署的代价完全可以忽略不计，对于现有的应用，启动耗时再长，也并非长到无法忍受，如果真的这么长，那更应该考虑的是如何进行模块拆分，分布式部署了。
对于无法停止服务的应用，比如现在的云计算平台这样分布式应用，采用分批上线也可以满足需求，类似热部署方案应该是放在最后考虑的解决方案。
2.开发环境
在生产中，不会有频繁的部署并且启动耗时长的应用，但由于云计算的兴起，热部署还是有其应用。
而热加载有点玩火，太危险了。但在开发和debug中，频繁启动应用却随处可见，热加载机制可以极大的提升开发效率。这两种机制，在开发中还有另外一种称呼—开发者模式。
对于大型项目：往往启/停需要等待几分钟时间。更浪费时间的是，对于一个类中的方法的调试过程，如果修改多次，需要反复的启停服务器，浪费的时间更多。
以目前的crm项目为例，其启动时间为5m，以一天debug重启十次，一个月工作20天来算，每年重启耗时25人日，如果能完全使用热加载，每年节省重启时间近1人月。
总结
在实际生产中热部署在云计算中运用挺多，但热加载没有，而在开发中，热加载可以显著的提升工作效率，强烈推荐使用热加载方式，不仅tomcat，大多数其他servlet容器也支持这种方式，大家可以自行搜索相关技巧。