一、热部署与热加载
在应用运行的时升级软件，无需重新启动的方式有两种，热部署和热加载。
对于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选项。
<Context reloadable="false"/>
OR
2.修改eclipse中的server配置
这样做可以在在修改代码之后，不会自动重启服务器，而只加载代码，新增一行java代码ctrl+s后直接刷新页面或调用接口即可看到效果，无需重启tomcat。
3.远程debug中使用tomcat热加载
tomcat的热加载机制不仅可以在本地debug时，tomcat的远程调试也支持热部署，通过eclipse debug远程到远程tomcat上，修改本地代码，ctrl+s后直接刷新页面后调用接口，即可发现远程tomcat已将本地代码进行了热加载。
4.jrebel插件方式
jrebel插件可以进行更彻底的热加载，不仅包括类，甚至支持spring 等配置文件的热加载，但公司项目开发环境复杂，目前在eclipse中配置一直没有成功，只能使用tomcat自带的热加载机制。
总结
在实际生产中热部署在云计算中运用挺多，但热加载没有，而在开发中，热加载可以显著的提升工作效率，强烈推荐使用热加载方式，不仅tomcat，大多数其他servlet容器也支持这种方式，大家可以自行搜索相关技巧。