Tomcat 支持通过启用 Context 的 reloadable="true" 实现 Web 应用自动重载（热部署），需确保编译输出指向 WEB-INF/classes，并规避类加载器残留、文件锁等问题；替代方案包括 tomcat7-maven-plugin 或 JRebel 等工具。
Tomcat 本身不支持像 Spring Boot DevTools 那样的“实时字节码热替换”，但可以通过配置实现 Web 应用的自动重新加载（auto-reload），也就是常说的“热部署”——即修改 Java 类、JSP、配置文件或静态资源后，无需手动重启 Tomcat，它会检测变化并自动重新部署应用。关键在于启用 reloadable 属性并确保开发环境满足条件。
启用 Context 的 reloadable 属性
这是最常用且有效的热部署配置方式，适用于将应用以目录形式部署在 webapps 下的情况。
- 打开
$CATALINA_HOME/conf/context.xml（全局配置），或在$CATALINA_HOME/conf/Catalina/localhost/yourapp.xml（单应用配置）中编辑 Context 元素 - 添加或修改
reloadable="true"属性，例如：
注意：reloadable="true" 会让 Tomcat 监控 /WEB-INF/classes 和 /WEB-INF/lib 下的变更，一旦发现 class 文件或 jar 更新，就会触发应用重载（stop → start）。
确保编译输出路径正确指
向 WEB-INF/classes
向 WEB-INF/classesIDE（如 IntelliJ IDEA 或 Eclipse）必须把编译后的 .class 文件输出到项目的 WEB-INF/classes 目录下，否则 Tomcat 检测不到类变化。
- IntelliJ：File → Project Structure → Modules → Sources → 确认 Output path 指向
out/artifacts/xxx/WEB-INF/classes或使用 “Build project automatically” + “Registry → compiler.automake.allow.when.app.running” - Eclipse：Project → Properties → Deployment Assembly → 确保 source folder 映射到
/WEB-INF/classes - 不要把 class 文件放在
target/classes等构建中间目录，Tomcat 不监控那里
避免常见失效原因
即使设置了 reloadable="true"，热部署仍可能“看似不生效”，多数源于以下情况：
- 类被 JVM 持有未释放：某些框架（如 Hibernate、Spring）或静态变量持有 classloader 引用，导致旧 ClassLoader 无法卸载，重载失败 —— 此时日志常出现 “Failed to stop application” 或 “The web application [...] appears to have started a thread”
- 修改了 web.xml 或 TLD 文件：这类变更会强制重载整个 Context，但需确保没有语法错误，否则加载失败且无明显提示
- Tomcat 运行在 IDE 外部，而 IDE 编译未触发：建议开启 IDE 自动编译，并确认 class 文件确实已更新到目标目录
- Linux 下文件系统 inotify 限制或 Windows 下文件锁：尤其是用记事本编辑 JSP 后未保存关闭，会导致 Tomcat 无法读取新内容
替代方案：使用 Maven + tomcat7-maven-plugin（适合快速测试）
如果标准热部署不稳定，可改用插件式部署，更轻量可控：
- 在 pom.xml 中配置：
tomcat7-maven-plugin
执行 mvn tomcat7:run 启动嵌入式 Tomcat，它会监听源码变化并自动 recompile + redeploy，适合开发阶段快速验证。
基本上就这些。Tomcat 的“热部署”本质是自动重载，不是真正的热交换；想获得更高级的类替换能力（如修改方法体不重启），需要配合 JRebel 或 Spring Loaded（已停更）等第三方工具。日常开发中，配好 reloadable + 正确输出路径 + 注意资源锁，已经能覆盖大部分迭代场景。
