Tomcat自动部署触发机制疑问：修改WEB-INF/classes文件为何触发重部署？

首先，你提到的reloadable="true"是触发这个行为的关键配置，我来给你拆解清楚Tomcat这背后的逻辑：

1. reloadable属性的核心作用 #

当你在Context配置中设置reloadable="true"时，Tomcat会启动一个后台监控线程，定期扫描Web应用的关键资源目录和文件，一旦检测到变化，就会触发应用的重加载——本质是销毁旧的Web应用类加载器，创建新的类加载器重新加载整个应用。

2. Tomcat监控的目标资源 #

Tomcat官方文档说“仅修改web.xml或Context XML文件才会触发”其实是一种简化表述，实际上当reloadable="true"时，Tomcat会监控以下几类资源的变化：

• 应用根目录下的web.xml（全局应用配置）
• WEB-INF/web.xml（应用自身的部署描述符）
• WEB-INF/classes目录下的所有文件和子目录
• WEB-INF/lib目录下的所有JAR文件
• Context XML配置文件（就是你配置的<Context>所在的文件）

也就是说，只要这些位置的资源有修改（包括创建、删除、修改内容，甚至用touch命令修改文件的最后修改时间），Tomcat的监控线程都会检测到。

3. 为什么修改WEB-INF/classes/app.properties会触发重加载 #

你执行的touch /myapps/myApp1/WEB-INF/classes/app.properties命令，修改了这个文件的最后修改时间，Tomcat的监控线程在扫描时发现WEB-INF/classes目录下的文件发生了“变化”（时间戳更新），就会判定应用资源需要更新，进而触发重加载流程。

这里要注意：Tomcat并不关心你修改的是Java编译后的.class文件还是普通的文本配置文件，只要是WEB-INF/classes下的资源，它都会监控——因为这个目录是Web应用类加载器的核心加载路径之一，任何变化都可能影响应用的运行逻辑。

4. 重加载的底层逻辑 #

当检测到资源变化时，Tomcat会执行以下步骤：

• 停止当前Web应用的所有Servlet和过滤器，销毁旧的Web应用类加载器
• 创建一个新的Web应用类加载器，重新加载WEB-INF/classes和WEB-INF/lib中的所有资源
• 重新初始化Servlet上下文，启动所有Servlet和过滤器，完成应用的重加载

这种设计是为了让开发者在不重启Tomcat的情况下，快速更新应用的代码和配置，提升开发效率。

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