做 Spring Boot 开发最烦的事情是什么我第一个想到的就是“改一行代码等二十秒启动”。以前做商城、校园讲座预约这类偏业务的项目时一天改几十次接口是很正常的每次一改就要重启然后看着控制台慢慢打日志好不容易容器起来了登录态没了测试数据也丢了又得重新走一遍流程。那种等待对写代码的人来说比写代码本身还消耗精力。Spring Boot 热部署就是专门解决这个问题的让代码修改后应用自动重新装载省掉手动重启的等待时间同时尽量保留运行上下文。这篇文章我会把 DevTools、JRebel 这些主流方案的原理和配置讲透重点落在 Spring Boot DevTools 的完整实操上包括 IDE 设置、配置项、常见坑和排查思路。无论你是在写一个几万行的老项目还是一个刚起步的小接口服务这套东西都值得花十分钟配好。1. 为什么 Spring Boot 项目要关心热部署1.1 传统开发流程的时间浪费到底有多大先算一笔账。假设你正在维护一个中等规模的 Spring Boot 项目启动时间大约是 15 秒这个速度在业务系统里已经算不错了。一次需求开发你平均每天需要为了验证代码修改重启应用 30 到 50 次那么光启动等待就花掉了 7 到 12 分钟。听起来好像不多但实际开发里远不止这些因为重启之后你还要回到浏览器重新登录、重新翻到操作页面、重新点击入口触发那个你正在调试的接口。这一来一回每次至少补上 1 到 2 分钟一天下来接近一个小时就没了。更让人难受的是节奏被打断。写代码需要保持思路连续而重启等待正好卡在“刚刚改完、马上验证”的高注意力节点上。你盯着进度条看了十几秒然后忍不住切出去回了个消息再切回来已经想不起刚才那段代码为什么要这么写了。我见过不少团队为了解决这个问题专门把项目拆成微服务每个服务启动速度控制在 3 秒以内但拆服务本身要付出的维护成本更高。更现实的办法是给单体项目配上热部署。1.2 热部署解决的三个核心痛点第一消掉重复启动开销。热部署不等于完全不重启而是足够快、足够自动。DevTools 这种方案通过类加载器隔离让第三方依赖不重新加载启动时间能压到原来的三分之一甚至更低。第二保留尽可能多的应用上下文。虽然做不到完全不重启但热部署之后缓存、静态字段、连接池的状态很多还能复用比冷启动后的干净环境更接近“刚才那台机器”。第三把动作变成全自动。保存代码、IDE 编译应用自己就重启了不需要你手动触发任何命令省掉“记得重启”这个心智负担。另外我想给刚开始接触 Spring Boot 的人一个概念热部署属于“开发效率工具”它和业务功能无关也和上线部署无关。生产环境里基本用不到它你也不应该把它带到线上。它只服务于一个目标就是让本地开发变快。2. 热部署方案选型DevTools、JRebel、Spring Loaded 怎么选2.1 Spring Boot DevTools 官方方案的正确认知Spring Boot DevTools 是官方提供的开发者工具模块它不是一个单独的工具而是一整套开发期辅助能力的集合。其中包括自动重启、静态资源缓存禁用、模板引擎缓存自动关闭、LiveReload 支持、以及远程调试协议。它的核心思路是用“双类加载器”机制把项目自身的类与第三方依赖的类分开管理改代码时只替换项目类的加载器而不是把整个 Spring 容器推倒重来。这里值得多说一句DevTools 的自动重启本质上仍然是一次 Spring 容器刷新并不是字节码层面的即时替换。所以它比 JRebel 慢但比完全冷启动快得多。对绝大多数中小型项目来说这个速度已经够用了。很多人一开始对 DevTools 有误解觉得配了它代码改了就能立刻生效连 JVM 都不用重启其实不是它是“快速重启”不是“零重启”。DevTools 还有个容易被忽略的点它默认只作用于本地 classpath 下的文件变化。也就是说只有当你修改了项目中的 .class 文件、配置文件、模板文件这些能被 classpath 感知的内容时重启才会被触发。如果你改的是外部依赖的源码或者本地仓库里的其他模块DevTools 不会自动感知除非你把它加进 additional-paths。2.2 JRebel 和 Spring Loaded 到底还有没有必要JRebel 是一种商业热部署插件原理是直接对 JVM 里的字节码做增强方法体改了之后不重启类加载器而是让原有类在运行时使用新版字节码。因此它的核心优势是“改完立即生效”几乎没有重启延迟尤其适合那种动一下就依赖大量初始化数据的项目。但我要负责任地说一句JRebel 需要正版授权价格不低团队要统一配置而且它和部分框架的字节码增强机制会有冲突排错成本并不低。除非你的项目真的到了启动 30 秒以上、DevTools 也无法忍受的地步否则我不建议从头就上 JRebel。Spring Loaded 是更早出现的方案它在 Spring Boot 1.x 时代有过一段应用期思路和 JRebel 类似也是做字节码重载。但它的社区维护基本停滞对 Java 新版本的支持也很滞后。新项目完全没必要考虑它老项目如果还在用我更建议尽快迁移到 DevTools。2.3 方案对比与选型建议方案原理成本延迟适用场景DevTools类加载器隔离 自动重启免费秒级到十几秒绝大多数 Spring Boot 项目JRebel字节码即时增强付费毫秒级启动特别慢、初始化代价大的项目Spring Loaded字节码重载免费毫秒级Spring Boot 1.x 老项目不推荐新用手动重启无无分钟级所有人被迫使用但效率最低我的选型建议很简单除非公司已经给团队批量买了 JRebel否则优先把 DevTools 配好、配对。很多项目配了 DevTools 觉得“没效果”其实都是细节没到位后面我会专门讲 IDE 设置和监听范围。3. DevTools 自动重启的原理拆解3.1 双类加载器机制到底是怎么回事DevTools 的核心实现是双类加载器。应用启动时DevTools 把第三方依赖 Jar 里的类交给 BaseClassLoader 加载把你在项目中编写、编译出来的类交给 RestartClassLoader 加载。当你修改了项目中的类并且 IDE 完成编译后DevTools 检测到 classpath 下有 .class 文件变化就会丢弃旧的 RestartClassLoader创建一个新的 RestartClassLoader 重新加载项目类。这个机制可以用生活中的例子来理解想象一个后厨有两口锅。一口大锅始终烧着汤除非厨房整体停工否则不改动它另一口小锅专门用来热当天新买的菜菜倒掉重新做只重刷小锅丝毫不影响大锅。你的第三方依赖就相当于大锅里的汤项目代码就是小锅里的菜。因为大锅没动所以 Spring 容器重新构建的时候大部分环境初始化工作都可以被跳过速度自然快。这个设计带来的好处有两个一是快二是不容易出错。如果每次重启都把所有类重新加载一遍那么第三方库里的静态单例、缓存状态、字节码代理都会重新初始化反而容易引入一些只在“冷启动”时才会出现的诡异问题。双类加载器把风险面缩小到项目代码本身。3.2 重启的触发条件与监听范围DevTools 启动后会注册一个文件监听器默认监听 classpath 目录下的文件变化。当你通过 IDE 执行编译将 .java 文件编译成 .class 并输出到 target/classes 目录时监听器发现文件有更新就会触发重启。需要注意不是所有文件变更都会触发重启。静态资源目录比如 src/main/resources/static下的 css、js、图片默认不会触发重启因为这类文件不需要类加载器参与只需要被静态资源处理器读取。模板文件templates 下的 html、ftl默认也不会触发重启DevTools 会直接禁用模板缓存让修改后的模板文件在浏览器刷新时重新读取。这个设计非常合理因为它避免了你改个样式、改行文案也要白白经历一次应用重启。但是有一个大坑DevTools 的文件监听依赖 IDE 的“自动编译”开关。IDEA 默认并不会在窗口失焦或文件保存时自动编译至少我经常遇到的“DevTools 完全没反应”就是这里出问题。这个操作步骤后面我会在实操部分详细讲。3.3 DevTools 对缓存与模板的额外处理DevTools 真正贴心的地方在于它对缓存的处理。Thymeleaf、FreeMarker 这类模板引擎为了性能默认开启缓存如果没有缓存禁用你改了模板文件也不会立刻看到效果。DevTools 会自动把 spring.thymeleaf.cache 和 spring.freemarker.cache 设为 false省得我们手动逐个配置。同时它还集成了 LiveReload这是一个浏览器端能力DevTools 启动时会在本地开一个小端口浏览器安装 LiveReload 插件后一旦检测到页面相关文件变化浏览器会自动刷新。这个功能听起来高大上但实际体验取决于浏览器插件环境和网络不一定每次都好使。我个人更习惯依赖模板引擎缓存被禁用这个能力改完直接手动按 F5反而更可控。4. 实操配置从零启用 DevTools 热部署4.1 在 Maven 和 Gradle 工程里正确引入依赖Maven 工程在 pom.xml 里加这段依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId scoperuntime/scope optionaltrue/optional /dependencyGradle 工程在 build.gradle 里加runtimeOnly org.springframework.boot:spring-boot-devtools为什么 scope 要设为 runtime、optional 要设为 trueruntime 保证它在运行期存在但不在编译期参与业务代码依赖optional 则确保它不会被传递到依赖此模块的其他工程。简单来说就是这玩意儿只管你本地开发不应该被当成一个普通依赖传播出去更不应该在你打成的 Jar 包里进入生产运行环境。4.2 application.yml 里的关键配置项DevTools 大部分功能开箱即用不需要写额外配置但你至少要理解几个常用项spring: devtools: restart: enabled: true exclude: static/**,public/** additional-paths: src/main/java livereload: enabled: trueenabled: true 表示开启自动重启注意如果把这里设为 falseDevTools 的其他功能不受影响但自动重启会关闭。exclude 用来声明哪些目录下的文件变化不触发重启比如 static/,public/这种静态资源目录改它们不需要重启应用。additional-paths 是额外监听路径默认 classpath 已经被监听如果你的源码目录不在默认 classpath 里就得手动加进去。这里我专门提一下 exclude 的一个细节如果你想排除的是“模板文件不重启但仍自动刷新”不要把它们配置到 exclude 里因为模板文件本来就不触发重启配不配没差别。exclude 真正适合放的是那些“改了你也不希望自动重启”的文件比如一些会频繁修改的自定义配置文件。4.3 IDEA 里的自动编译设置才是关键这是整个配置环节里最容易出问题的地方我把它单独拎出来讲。IDEA 默认并不会在代码保存后自动编译整个项目如果 IDE 没有把最新 .class 文件输出到 target/classesDevTools 就感知不到文件变化自然也就不会触发重启。第一步打开 Settings - Build, Execution, Deployment - Compiler勾选 Build project automatically。第二步旧版本 IDEA2020 到 2021.2 左右需要按 Ctrl Alt Shift / 打开 Registry找到 compiler.automake.allow.when.app.running 并勾选。新版本 IDEA2021.3 之后把这项挪到了 Settings - Advanced Settings - Compiler里面有一个 Allow auto-make to start even if developed application is currently running把它勾上。这两步做完记得重启 IDEA。很多教程漏了第二步导致“明明勾了自动编译DevTools 还是一动不动”。如果你用 Eclipse问题会少一些因为 Eclipse 默认保存即编译配合 DevTools 会自然多出重启行为。4.4 验证热部署是否生效配完之后怎么确认真的生效了最直接的方法是看控制台日志。启动应用后修改任意一个 Controller 里的方法保持 IDEA 窗口处于当前状态等待编译完成如果 DevTools 正常工作控制台会出现类似下面的日志Restarting Spring Boot application...然后应用会自动完成 Spring 容器刷新不会执行一次完整的 JVM 冷启动。你可以项目动一下计数器或者打印当前时间对比两次日志里的时间间隔如果明显比冷启动短说明双类加载器机制已经在发挥效果了。还有一个小方法把日志级别调到 DEBUGDevTools 会打印更详细的重启原因比如哪个文件触发了重启。排查时很有用但平时不建议长期开着。5. 热部署的进阶玩法与常见组合场景5.1 和 MyBatis-Plus 配合时需要注意什么热词里提到了 MyBatis-Plus 的 XML 和 Mapper 文件配置问题这里展开说。MyBatis-Plus 的 Mapper 接口是 Java 接口编译后会产生 .class 文件只要它在项目 classpath 下改接口方法名、加注解DevTools 都能感知到。但 XML 映射文件就不一样了它属于资源文件如果你把 XML 放在 src/main/java 下的同一个包里而不是放在 resources 目录只有配置了 resource 插件才能把 XML 也编译到 classpath。更合理的做法是把 XML 统一放在 src/main/resources/mapper 目录然后配置 MyBatis-Plus 的扫描路径mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml这样项目正常编译后XML 会出现在 target/classes/mapper 下DevTools 对资源文件变化同样敏感你改 SQL 语句、改 resultMap保存后应用自动重启不用手动触碰。我在实际项目里见过有人为了省事把 XML 和 Mapper 放同一个目录结果每次都要手动执行一次 Maven 的 resources 插件才能把 XML 刷新进 targetDevTools 根本监听不到这就是自找麻烦。5.2 大项目里的备用招数单独监听源码目录如果你的项目是多模块结构比如父工程包含 common、dal、web 三个模块你在 web 模块里改代码DevTools 只监听 web 模块的 classpathcommon 模块的改动不一定能触发重启。解决办法是在启动类的配置里把 common 模块的源码目录加进 additional-paths但更干净的做法是直接用 IDE 的多模块构建功能让修改后的模块重新编译输出这样 classpath 变化依然能被感知到。我自己的经验是多模块项目里优先保证被修改的模块被重新 build。IDEA 的 Build 操作只构建当前模块时DevTools 可能只能感知当前模块的变更而不会自动重建其他模块。你需要手动触发一次 Build Project或者调整一下 IDAE 的 build 配置让所有模块都参与自动编译。这一步在团队协作时尤其重要否则别人改了公共模块代码你这边怎么保存都不触发重启。5.3 与前端模板引擎、LiveReload 的实际体验对于 Thymeleaf 这类服务端渲染模板DevTools 会自动把缓存关掉所以你改完 HTML 之后刷新浏览器就能看到新页面不需要任何重启。配合 LiveReload 的话还会自动刷新浏览器省一次 F5。FrreMarker、Velocity 同理。但要注意如果你的项目用的是前后端分离模板引擎只是用来做静态页面的托管那前端资源的刷新纯粹靠静态资源加载和 DevTools 的模板缓存关闭没有直接关系。前端构建工具如 webpack 的 devServer有自己的一套热更新和 Spring Boot DevTools 完全是两码事别混在一起排查。5.4 远程开发场景下的 DevTools 要怎么处理如果你习惯在一台远程服务器上跑 Spring Boot 应用然后本地通过 IDE 远程调试DevTools 的远程协议可以在一定程度上支持远程热部署。它需要你在启动应用时开启远程连接配置 spring.devtools.remote.secret 密钥本地 IDE 再把运行方式改成 Remote Spring Boot 类型。但这里我要泼盆冷水远程模式的安全性很难保障密钥一旦泄露等于把一个能执行任意重启的通道暴露在网络里。没有足够的网络隔离和安全保障不建议在真实环境里开这个功能。我个人更推荐远程场景回退到常规方案本地开发用 DevTools 保证快速迭代远程环境保持稳定运行不要为了省几次重启而引入不必要的攻击面。6. 常见问题与排查实录6.1 DevTools 配了但完全没反应这是频率最高的问题。按下面顺序排查pom 或 build.gradle 里的依赖是否正确加上了scope 是否为 runtime。IDEA 的 Build project automatically 是否勾选。IDEA 的 Advanced Settings 里是否勾选 Allow auto-make to start even if developed application is currently running。控制台启动时日志里有没有出现 DevTools 的启动标记比如 “DevTools” 相关字样。确认你启动的不是已经打包好的 jar。如果你用 java -jar 启动本地构建产物DevTools 默认也是会尝试启用的但不一定能正确感知源码目录所以本地开发请用 main 方法或 mvn spring-boot:run 启动。有一个我踩过的坑项目里没有直接用 spring-boot 插件来启动而是通过外部 Tomcat 或自定义类加载器启动DevTools 的自动重启在这种情况下很可能不生效。原因很简单DevTools 的重启机制依赖对 classpath 变化的监控和自有类加载器的控制一旦框架接管了类加载过程它就很难插手了。6.2 改 Java 文件触发了重启但效果没变如果你改了代码控制台也出现 Restarting 日志但运行结果还是老逻辑先想想编译是否真的成功。IDEA 有一个很隐蔽的问题当你修改了代码但编译失败时IDE 不会输出新的 .class 文件DevTools 自然拿着旧 class 跑。解决方法是看 IDEA 底部编译输出窗口有没有报错信息同时单独点击一次 Build - Build Project 强制看结果。另一个可能是 IDEA 的增量编译没有覆盖到你修改的那个文件。这种情况多见于模块特别多、或者文件目录结构比较特殊的工程里。可以尝试点击 Build - Recompile 单文件来强制输出。6.3 热部署之后登录态丢失、Spring Security 失效这是 DevTools 重启方案的一个天然短板。因为 RestartClassLoader 被替换后项目类里的 Session 存储等相关状态会重置如果你把 Session 存到了本地内存重启后用户自然就掉线了。对策有几个层次最简单的把 Session 存储切换到 Redis 等外部存储这样重启不会丢失会话数据再要么开发环境降低 Spring Security 校验强度比如关闭 csrf、放宽部分路径最实际的是在本地开发时使用一个固定测试账号或者干脆在调试模式下跳过登录拦截。我自己的习惯是开发环境用一个 profile专门把安全配置简化到只做基本的登录拦截不让热部署的会话问题天天打断思路。6.4 重启越来越慢甚至内存越来越大DevTools 每次重启都会创建一个新的 RestartClassLoader如果项目类特别多或者某次重启中旧的类加载器没被及时回收老年代和 Metaspace 就会逐渐膨胀。最典型的表现是重启第三次之后速度明显变慢再过几次直接 OutOfMemory。排查时可以先看一眼 Metaspace 的使用量如果持续上涨可以在 JVM 参数里加 -XX:MaxMetaspaceSize 来限制但这只是治标。根本解决办法是定期关闭一次应用做冷启动给 JVM 一个彻底清理的机会。如果你发现某一次重启特别慢多半是 DevTools 在扫描大量额外路径检查一下 additional-paths 是不是配了过大的目录。6.5 和第三方字节码代理库的冲突某些框架会做字节码增强比如 MyBatis 对 Mapper 接口的代理、Spring Security 的代理、以及各种 AOP 切面。当 DevTools 用新的 RestartClassLoader 重新加载项目类后可能出现代理对象仍然引用旧类的情况表现出来就是“改了代码但代理行为没变”或者“莫名其妙的 ClassCastException”。遇到这种问题先用一个最小样例确认是不是热部署本身的问题然后看第三方库是否有对 DevTools 的兼容说明。大部分主流库都能兼容但我见过一个老版本的 sharding-jdbc 在热部署后出现连接池代理混乱的问题。解决方案也不复杂要么升级库版本要么放弃对该模块的热部署要么把特定库移到 BaseClassLoader 的加载路径里。整体来说这类问题比例不高遇到了集中排查一下就好。6.6 日志配置与热部署的交互Logback 本身提供了 scan 配置可以定时重新加载日志配置文件但如果你和 DevTools 一起用偶尔会遇到重启后日志级别被重置的情况。原因是日志上下文初始化发生在 Spring 容器早期阶段而 DevTools 重启时也会重新初始化日志两者叠加会产生状态错乱。我的建议是日志配置用 logback-spring.xml而不是 logback.xml。如果用 Spring Boot 的配置属性来控制日志级别比如 logging.level.com.exampleDEBUGDevTools 重启后大概率会正确读取最新配置。如果你遇到日志改了半天不起作用先确认到底是不是 DevTools 重启导致的问题再看 logging 配置文件的加载顺序。7. 一些长期使用后的个人体会如果把 DevTools 整个用熟我的感受是它不像一个“功能开关”更像一个开发习惯的改造器。以前我改代码之前要先想想这次改了会不会触发重启现在完全不用想保存之后该干嘛干嘛几秒钟回来控制台已经提示 Restarting 完成。这种感觉一旦享受过就再也回不去一行代码等十秒的日子了。最后分享一个小技巧。每次项目跑起来以后我习惯先用一个简单的健康检查接口预热然后在此基础上做后续开发。配上 DevTools 后我会刻意把启动日志里那次重启的耗时记住如果某一天重启时间突然翻倍了一定不是 DevTools 变慢了而是我在哪个地方引入了特别耗时的 Bean 初始化逻辑或者状态清理逻辑这反而是个很好的代码质量信号能提醒你回头审视刚刚那段新增代码。热部署的价值不只是省时间它还在用“快慢变化”悄悄反馈着工程本身的健康度这是我用了很久才体会到的一层价值。