Tomcat work目录

背景：

某老项目维护，由于种种原因，只能是本地编辑器编译调试了以后，将修改后的
代码重新编译，用新编译的.class文件、jsp文件来替换老文件。

问题描述：

• 操作：四台服务器，用的是相同的tomcat。将新的应用打包放到webapps目录下。
• 结果：访问相同页面，两台服务器页面正常，两台不正常。
• 排查：仔细检查了代码，webapp目录下应用的代码完全相同，复制粘贴了好几次。
• 原因：原来，前几天调试新功能的时候，在两台服务器（当前显示不正常的）上，修改了一个jsp页面。tomcat work目录下，有同名的jsp编译后的_jsp.class文件。
• 解决： 删除work目录下的应用目录，遂正常。

根本原因：

在jsp页面第一次被访问的时候，将会生成jsp对应的xxx_jsp.java文件，然后编译成.class文件，并在Tomcat的work目录根据应用路径，生成相应的目录，放置java以及.class文件。
jsp是运行时编译，真正对外进行服务的jsp，其实就是这个“work”工作目录下的
.class文件。

《Tomcat与JavaWeb开发技术详解》书中有详细介绍，引用一段：

浏览器访问某JSP页面，容器接收到客户端访问某特定JSP文件的请求时，按照下面流程处理请求。
1. 查找该JSP页面对应生成的Servlet，如果已经存在，那就调用它的服务方法。
2. 如果该JSP页面对应的Servlet不存在，就解析文件系统中的JSP文件，生成一
个Servlet.java文件，接着把这个.java文件编译成.class文件，然后初始化，运行
Servlet。
一般来说，找JSP文件，将它翻译成.java文件，并编译成.class文件的过程，是在客户端首次请求这个JSP页面的时候发生。（算是懒加载吧）

• 运行中修改JSP
  在web应用处于运行状态时，如果原始的JSP文件被更新，多数容器能检测到所做的更新，既而自动生成新的Servlet源文件并进行编译，然后再运行新生成的Servlet。

• 特殊情况
  在少数情况下，如果更新JSP文件后，通过浏览器还是看到的旧的网页，有可能是因为Tomcat使用的还是work目录下的旧Servlet类文件，此时可以手工删除work目录下的相关Servlet文件，这样可以保证Tomcat宠幸编译修改后的JSP文件。

下面这篇，还介绍了Tomcat是定时检测JSP更新，然后编译的。
[tomcat的work目录作用]https://blog.csdn.net/u014057054/article/details/47950905