Tomcat重启后Class文件未更新？已设reloadable=true求协助

我来帮你梳理下可能导致这个问题的常见原因，我自己也碰到过好多次类似情况：

• 先纠正一个核心误区：WEB-INF/classes目录是存放编译后的.class文件的，不是Java源文件。你直接把修改后的.java文件放到这里，Tomcat是不会自动编译它们的！Tomcat的reloadable机制监听的是class文件、配置文件的变化，而非Java源文件。所以第一步，你需要先把修改后的Java文件编译成.class文件，再替换到classes目录的对应位置。

• 检查reloadable配置的匹配性：你提到在server.xml的<Context>节点设置了reloadable="true"，但你的节点配置是<Context docBase="Book" path="\Book" reloadable="true">，而你的应用实际部署在Tomcat\webapps\program目录下——这俩完全不匹配！这个Context节点对应的是名为Book的应用，对你修改的program应用根本不起作用。解决方法：

  • 要么修改这个Context节点的docBase为program的实际路径，path改为/program；
  • 要么删掉这个自定义Context节点，Tomcat会自动识别webapps下的program应用，此时如果需要开启热重载，可以在应用自己的META-INF/context.xml里添加reloadable="true"配置。

• 确认Tomcat是否真正重启成功：有时候看似重启了，但Tomcat进程可能没完全终止，旧的class文件还驻留在内存中。你可以：

  • Windows系统：打开任务管理器，找到所有java.exe或javaw.exe进程，全部结束后再重启Tomcat；
  • Linux/macOS系统：执行ps aux | grep tomcat找到进程ID，用kill -9 <进程ID>杀掉后再重启。

• 清理Tomcat临时缓存：Tomcat的work目录会生成应用的临时编译文件，旧缓存可能导致更新不生效。你可以删掉Tomcat/work/Catalina/localhost/program（对应你的应用名）目录下的所有内容，然后重启Tomcat。

• 检查文件权限：确保替换的.class文件有足够的读取权限让Tomcat进程访问。比如Linux下要保证Tomcat运行用户对classes目录及文件有读权限；Windows下如果Tomcat是用管理员权限启动的，替换文件时不要出现权限被拒绝的情况。

• 排查WAR包部署的覆盖问题：如果你的program应用是通过WAR包部署的，Tomcat启动时会自动把WAR包解压到webapps/program目录。如果你直接修改解压后的classes文件，下次Tomcat重启时可能会重新解压WAR包覆盖你的修改。这种情况下，你需要修改原始WAR包中的文件，或者将应用改为解压后的目录形式部署（删除WAR包，只保留解压后的program目录）。

内容的提问来源于stack exchange，提问作者user9695387