1.情景说明
在eclipse中，为什么Java文件修改后，重启tomcat class文件才能生效？
为什么jsp修改后，不需重启tomcat就能立即生效？
为什么静态资源（*.js，*.css，*.html，图片、pdf）等文件修改后，会即时生效？
2.探究eclipse的自动构建功能（Build Automatically）
自动构建的对象：src目录下的所有文件；
src目录被指定用来存放Java源文件（*.java）及配置文件（*.xml,*.properties等），也可以存放其它格式文件。
自动构建功能有2层含义：
其一，Java文件；
当Java文件有变动（Java文件被创建、修改、删除）时，eclipse会自动调用jdk的编译命令，
将Java文件编译成class文件并输出到WEB/INF/classes目录下。
其二，非Java文件（如：配置文件）。
当配置文件有变动（Java文件被创建、修改、删除）时，不管是什么样的文件格式，只要是存在于src目录下，
eclipse都会自动将其复制到WEB/INF/classes目录下。
证明：
测试一：修改LoginAction.java文件
修改前
修改后：
测试二：在src目录下新建一个text文件
WEB-INF/classes目录下同样被复制了一份
关闭自动编译功能，将导致Java文件修改后不会被重新编译， 配置文件不会同步！
测试三：删除配置文件txt
先关闭自动构建功能（取消勾选即可）
在eclipse中，刚才新建的txt文件删除
你会发现：WEB-INF/classes目录下该文件并没有被删除。
重新勾选上 Build Automatically
WEB-INF/classes目录下该文件已经被删除。
3.在eclipse中，项目开发阶段，探究运行JavaWeb项目的常用的4种方式及区别
方式一：选中项目-->右键-->Run As-->Run on Server
方式二：选中项目-->右键-->Debug As-->Debug on Server
方式三：将项目拷贝到tomcat的webapps目录下，启动tomcat；
方式四：修改tomcat的server.xml，在Host标签内配置Context标签，启动tomcat。
探究一：
前提：项目发布在tomcat的webapps目录下；
当文件内容发生变化后，是eclipse将变化后的文件更新至tomcat，还是tomcat自动将更新后的文件拷贝至webapps目录下？
前两种方式，通过eclipse自动将项目发布至tomcat的webapps目录下；
第三种，自己手动将项目拷贝至tomcat的webapps目录下。
测试1：第一种发布方式测试
打开base_login.js
打开webapps下对应的该文件
在eclipse中修改该文件
切换到notepad++，你会发现该文件同样发生了变化
至此，我们还分不清到底时eclipse更新了该文件还是tomcat更新了该文件。
测试2：第三种发布方式测试
在eclipse中修改base_login.js文件后，webapps下对应的该文件并未发生变化！
2018/11/16
测试3：关闭eclipse中负责启动这个项目的tomcat的自动发布功能
切换到server窗口
双击打开你要修改的tomcat，选择第一个（默认为第二个），保存，不用重启tomcat就会生效。
对文件进行修改后，webapps目录下该项目对应的文件并未更新！
结论：
在eclipse中，所有格式的文件发生变化后（文件新增、修改、删除），要想实现将更新后的资源自动发布至tomcat，需要满足2个条件：
其一：通过eclipse将项目发布至tomcat的webapps目录下，判断依据：
对应的服务器下会展示已经发布的项目。
其二：需要开启“当资源发生变化时，自动发布至tomcat的检测功能”（这个是默认选中的）。
第三种方式之所以不能实现实时更新，是因为不能满足第一个条件！
原生的tomcat是没有第二个功能的；
所以说，是eclipse负责将变化后的文件更新至webapps中的对应项目下，
与原生的tomcat服务器无关，它只负责从webapps对应的项目下读取文件！
探究二：
前提：前3种发布方式中，
哪种发布方式，eclipse会自动将class格式文件更新至tomcat？
测试3：debug模式下运行项目(debug as)
打开LoginAction.java
在tomcat的webapps目录下找到并使用Java反编译工具打开该文件
修改该文件
使用反编译工具重新打开对应的文件
tomcat服务器被重新启动
访问这个Java类对应的controller，控制台输出结果：
测试4：普通模式下运行项目(run as)
在eclipse中修改LoginAcion.java文件后，webapps下对应的class文件并未发生变化！
结论：
手动将项目拷贝到webaps目录下进行发布项目，在eclipse对文件进行修改后，并不能实时更新文件，这种方式只适合项目正式运行阶段使用；
只有以Debug as方式发布项目，eclipse才会将class格式文件更新至tomcat。
探究三：
不管是以run as还是debug as的形式发布项目，
当jsp文件发生变化（文件新增、修改、删除）时，eclipse会自动将变化后的文件更新至tomcat的webapps目录下对应文件。
为什么？因为eclipse为tomcat推送的是jsp文件，tomcat负责将jsp转换成servlet，并编译成class文件
测试5：tomcat负责jsp的编译工作
jsp文件被编译后会被放到tomcat的work目录下；
只有请求时才会对jsp文件进行编译；
每个目录下都有jsp文件
因为只请求了登录页面，所以tomcat只对其对应的jsp进行了编译工作
每次对该页面进行请求时，tomcat都会检测对应的jsp文件是否更新，如果已经更新就会对其进行重新编译。
jsp处理流程图
探究四：
配置Context标签发布项目（热部署）的方式，直接启动tomcat即可。
具体方法：在eclipse中修改响应的tomcat的server.xml
在Host标签内添加Context标签
<Context docBase="D:\workspace-eclipse\jkkywpt_pydzk\web" path="/jkkywpt_pydzk"/>
tomcat的Context标签的docBase属性的值指定为web项目的发布目录（WebContent/WebRoot）后，启动tomcat后，
tomcat会直接访问将该目录下的文件并将其加载到tomcat容器中，不会再将项目发布到webapps目录下；
测试6：tomcat不会再将项目发布到webapps目录下
启动tomcat
webapps目录下并未发布该项目
因此，eclipse就省去了将更新后的资源推送到tomcat的webapps目录下的步骤。
测试7：eclipse中tomcat服务器的 “当资源发生变化时，自动发布至tomcat的检测功能”会失效。
关闭tomcat的自动发布功能
普通模式下，启动tomcat
base_login.jsp页面的原标题为aaa
浏览器展示效果
修改标题为测试
刷新页面后
由此，已经证明： eclipse的服务器的自动发布功能已经不起作用了。
测试8：只有在debug模式下运行项目，Java文件修改后会即时生效！
普通模式下，修改LoginAction.java文件
class文件已经更新
页面请求后，控制台并无输出内容
debug模式运行该项目
修改Java文件
浏览器刷新后，控制台输出结果：
由此，可以证明：在eclipse中，只有在debug模式下，无需重启tomcat，Java虚拟机会即时生效。
原理说明：
对于Java类的更新：当监听到class文件被修改后，通过动态修改内存中的字节码，将修改过的class文件再次装载到JVM中；
对于jsp的更新：jsp每次被调用时，tomcat容器都会通过ClassLoader重新加载相应的jsp编译后的class文件并装载到JVM中，
tomcat在调用jsp前，会检测该文件是否被更新，如果被更新，会重新编译这个jsp文件。
注意：
只有在修改方法体内的Java代码这一种情况，不需要重启tomcat！
4.总结
总的来说，文件修改后，之所以不用重启tomcat是因为eclipse的自动构建功能，
自动构建，将文件更新至tomcat的webapps目录下（class文件除外）；
普通模式运行下，java文件重新编译后，并不会被推送至webapps目录下；
debug模式运行下，java文件重新编译后，class文件会被推送至webapps目录下，并且被tomcat更新至JVM；
jsp文件之所以不用重启tomcat，也是依赖于eclipse的自动构建功能；
tomcat负责jsp的编译工作。
发布及运行项目，对比说明：
拷贝至webapps下发布项目：
运行方式：将项目拷贝至weapps目录下或者将项目打成的war包再放到weapps目录下
需要说明的是：tomcat并不是从war包解读所需文件，而是将war进行解压，也就是说tomcat本身并识别war包，只是被赋予了一个解压功能而已！
tomcat运行后，自动执行了解压功能
是否指定解压功能依赖于server.xml中Host标签的unpackWARs属性，默认值为true
特点：这种方式只适合在运行阶段使用；
缺点：不适用于开发阶段，无法进行代码调试！
使用eclipse发布项目，并以普通模式运行项目（run）：
当Java文件发生变化后，不会即时生效的原因有二：
其一，tomcat里的对应class文件并未更新，
其二，eclipse中，只有debug模式启动项目，Java代码才会即时生效。
特点：适合开发阶段使用，但不建议使用；
缺点：不重启tomcat的前提下，只适合前端调试，修改Java文件，必须重启tomcat。
使用eclipse发布项目，并以debug模式运行项目（debug）：
当Java文件发生变化后，可以即时生效的原因有二：
其一，tomcat里的对应class文件被同步更新，
其二，在eclipse中，以debug模式启动项目，Java代码会被更新至Java虚拟机，因此会即时生效。
特点：适合开发阶段使用，大部分人会使用。
当Java文件修改后，eclipse虽然会将更新后的文件更新至tomcat，但是默认会重启tomcat。
如何关闭tomcat重启？见文末推荐。
（因为就算是不重启tomcat，jvm也会即时生效）
缺点有二：
其一，Java文件修改后，会重启tomcat，我们必须等待项目重启后才能操作；（通过上面的方式可以解决）；
其二，eclipse会将项目发布至tomcat的webapps目录下，当我们不需要改项目时，需手动将其删除。
配置Context标签发布并运行项目（热部署）：
这种方式就是我们常说的热部署！
运行方式：直接启动tomcat（普通模式、debug模式）；
特点：适合开发阶段使用， 推崇以debug模式启动项目。
优点：
加载的项目会随着的tomcat的启动和关闭而产生或死亡，不会留下任何痕迹（work文件夹除外）；
而将项目发布到tomcat的方式，实际上是将项目发布到tomcat指定的发布目录webapps文件夹，需要将清理webapps文件夹才能保证只加载该项目到tomcat中；
而采用热部署的方式不会直接从WebContent目录下读取项目，不会在tomcat的webapps下产生任何文件；
方便调试、Java代码方法体内代码修改无需重启；
当然了，可以在server.xml下配置多个项目。
原文地址：https://www.cnblogs.com/hongjiahui/p/12591537.html