tomcat启动后class文件会接受请求加载到jvm中。而对jsp第一次请求时，会先编码成对应的.class文件加载进来。以后每一次请求tomcat容器要检查jsp的版本，如果与前一次不一样，则会自动再次编码并加载.class文件。
context节点中确定reloadable设置为true。确定下自己的项目是怎么部署在tomcat的，还是要看server.xml文件中的context节点，看下该解冻中是否多了antiJARLocking="true"和 antiResourceLocking="true"这两个属性配置
如果多了也就是说明该项目实现了热部署了，如果这个参数为true,那么将组织任何文件锁。这将明显的影响应用的启动时间，但允许webapps，可能发生锁的平台和配置下，支持完整的热部署和热卸载。
如果不配置，默认值是false如果设置为true,有一些副作用，包括屏蔽了JSP文件在运行服务器上的重新加载。
如果设置为true,且部署在Host的AppBase目录外面（默认是webapps），在Tomcat关闭的时候将导致应用被删除。 最主要的就翻译到这里了。
实际上，如果为false,因为存在锁，在你重新发布的时候，可能出现部分代码无法更新。因为原始文件可能因为被锁住了，不能删除。
当然，如果为false，那么部署的目录就是和包名相同了。如果是false,则会每次都放到一个临时目录下面，一个temp目录。这也是这个配置引发的一个副作用。
另外的一个类似的配置 antiJARLocking 是防止jar类库被锁定而无法删除这个作用的。所以如果我们通过eclipse自动部署的方法后在server.xml文件一直存在antiJARLocking="true"和 antiResourceLocking="true"的话就要考虑使用手动去部署试下了。
tomcat在启动时一次性加载所有的类，修改后，重启才能重新加载，修改才会生效。（修改jsp页面不用）。如果不想重启，可以通过修改配置文件来实现：
找到部署tomcat的服务路径(譬如:D:\Tomcat6.0\apache-tomcat-6.0.36\conf),解释:tomcat路径就是运行项目的部署服务器路径。在conf文件夹下找到server.xml文件 修改里面的reloadable=true 为reloadable=falsereloadable属性属于您部署项目的<context/>标签的属性。譬如:<Context debug="0" docBase="D:\JavaCode\E-bsoft\CDCPro\WebRoot" path="/CDCPro" reloadable="false"/>
