tomcat的work目录的作用

最近发现，很多网友喜欢把tomcat的work目录里的东西叫做缓存，其实那不是很恰当，work目录只是tomcat的工作目录，也就是tomcat把jsp转换为class文件的工作目录，这也正是为什么它叫work目录而不是cache目录的原因。 　

　    jsp，tomcat的工作原理是当浏览器访问某个jsp页面时，tomcat会在work目录里把这个jsp页面转换成.java文件，比如将index.jsp转换为index_jsp.java文件，而后编译为index_jsp.class文件，最后tomcat容器通过ClassLoader类把这个index_jsp.class类装载入内存，进行响应客户端的工作。

　　tomcat会定时稍描容器内的jsp文件，读取每个文件的属性，当发现某个jsp文件发生改变时（文件的最后修改时间与上次稍描时不相同时），tomcat会重新转换、编译这个jsp文件。但是tomcat的稍描是定时的不是实时的，这也正是为什么jsp文件修改后需要几分钟的时间来等修改过的jsp生效。当然为了即刻生效，很多老前辈都会建议在修改jsp页面后立即清除work目录里的文件。

　　另外，tomcat容器中，对转换后的java文件（比如：index_jsp.java）的编译最大只支持64k，所以在其他容器中的jsp移植到tomcat容器中时会遇到大jsp文件会发生无法编译的情况，所以建议把jsp中的业务逻辑写入单独的类，在jsp中通过调用这个类的静态方法来执行，并将jsp页面中的js提取出来放到单独的js文件内。

另一篇的记载：

1    用tomcat作web服务器的时候，部署的程序在webApps下，这些程序都是编译后的程序（发布到tomcat的项目里含的类，会被编译成.class后才发布过来，源文件没有发布过来，但这里的jsp没有经编译的）。tomcat有一个work目录，里面存放了页面的缓存，访问的jsp都会编译（从work里进入Catalina后的如localhost站点文件夹下的项目，我们可以看到那些jsp页面会被编译成应该是servlet文件，下次再来访问时，就直接运行servlet类就可以向客户端反应响应页面了，所以有的博客说第一次访问时会比较慢，是因为新发布上去的页面在第一个人访问时，会先编译成servlet文件，所以慢了，一旦编译好，那么除非jsp页面修改，不然下次访问直接运行servlet就可以响应用户，所以快），编译后的文件都会存储在work目录下。而tomcat显示的目录，都会从这个缓存里找编译后的jsp对应的class文件。所以当清空了work目录后，该过程将会从新来过。    
    有的时候会遇到一个问题，就是修改后的页面在tomcat运行的时候显示不了修改后的痕迹。这个时候删除work目录下对应的项目文件夹，重新启动tomcat就可以了。

2   在tomcat的conf配置文件夹下的server.xml文件里配置了Host name后，就会在conf下的Catalina文件夹和work下的Catalina文件下建立站点名称的文件夹，项目每次发布都会放入来，也会记录到conf下的Catalina文件夹的配置文件里去。

另外一个博客的思路：

/**
*今天在写一个jsp页面时，出错了。然后我就修改了以前的页面，可重新部署并重启服务器之后，显示的还是以前的内容 ，百般无奈，上网搜了一下，原来把Tomcat中，work目录下的东西删除就OK了。
*/ 下面的是转载的：
相信很多用Tomcat的人都会重复这样的事

1. 关闭Tomcat
2. 打开tomcat/work目录
3. 删除Catalina目录
4. 运行Tomcat

其实可以用RD命令删除整个目录，只需打开 tomcat/bin/startup.bat 文件，在开头加入
rd/s/q "C:\Tomcat 5.0\work\Catalina"
路径根据自己实际情况做修改

这样每次启动Tomcat的时候就会先删除页面缓存了，不用担心页面修改后没被重新编译

原文出处：https://blog.csdn.net/u014057054/article/details/47950905