1. 改代码就得重启先聊聊热部署方案的选型逻辑Spring Boot 开发最磨人的一件事就是你改一行日志、调一个参数然后眼睁睁看着应用重启、等端口起来、再重新点一遍页面。如果是大项目一次重启二十秒起步一天重启几十次大半天时间就这么浪费掉了。所以我刚接触热部署的时候第一反应就是一定要用但真正落地的时候才发现热部署不是加一个依赖就完事的东西它涉及到方案选型、工具链配合、类加载机制的理解还有一堆看起来玄学的不生效问题。先厘清一个概念热部署Hot Deployment和热替换Hot Swap在严格意义上不是一回事。热替换指 JVM 层面支持在调试器里替换已经加载的方法体旧版本 JDK 只支持方法体替换加了字段或改了方法签名就没戏热部署则是整个应用层面的类重新加载范围更广Spring Boot 生态里最常见的就是spring-boot-devtools。两个概念容易混但理解了它们的区别后面排查问题会轻松很多。主流的 Spring Boot 热部署方案大致有几类方案原理成本适用场景spring-boot-devtools自定义类加载器自动重启应用上下文低一个依赖日常开发通用性最好IDEA 自动编译 调试模式 Hot SwapJVM 层面的方法体替换零成本仅改方法体内逻辑不新增字段/方法JRebel字节码增强类结构级替换商业付费大型项目、微服务集群追求极致效率DCEVM动态代码演化虚拟机修改 JVM 支持更深的类演化中需替换 JVM老项目遗留调试场景为主这里面有一个常见误区很多人以为在 IDEA 里开个自动编译调试模式下改代码就能自动生效其实普通 Hot Swap 只支持方法体内部的修改。我实测过往类里加一个字段JVM 直接报UnsupportedOperationException提示 Hot Swap failed。也就是说如果你只是改一个方法里的一行逻辑IDEA 免费的热替换够用一旦涉及新增属性、改方法签名、改注解必须上 devtools 或者 JRebel 这种级别的东西。从个人体验来说我觉得 devtools 是性价比最高的起点。它不需要改 JVM、不需要付费、社区文档也多唯一的问题是有不少隐蔽的坑比如和构建工具打架、配置不生效、类加载器隔离导致的诡异异常。这篇文章我就以 devtools 为主线把原理到实操再到排错完整串一遍最后说说 JRebel 和容器化场景下的替代思路看完整套东西你应该能自己判断项目该用哪种方案。2. devtools 的类加载器机制自动重启为什么比手动重启快先回答一个很多人会问的问题devtools 的自动重启本质上是重启应用那和手动重启有什么本质区别如果只是自动化了启动动作那省下的也只是点鼠标的时间。实际不是。devtools 的核心巧妙之处在于它用了两套类加载器。当你启动 Spring Boot 应用时devtools 会创建一个RestartClassLoader重启类加载器和一个BaseClassLoader基础类加载器。项目里你自己写的类、资源文件由重启类加载器加载而第三方依赖的 jar 包、Spring 框架本身的类则由基础类加载器加载。当你修改了代码触发重启时devtools 只丢弃旧的重启类加载器并用一个新的替代它基础类加载器原封不动地复用。这么设计的好处是基础类加载器里已经缓存的那些第三方类Spring 容器一大堆内部类加载起来非常耗时不需要重新加载重启成本被压到了最低。我做过一次粗略统计一个中等规模的 Spring Boot 项目完整重启大概 15 到 20 秒而 devtools 触发的重启一般在 3 到 5 秒内完成差距主要就来自这个类加载器复用机制。理解了这套机制有几个实际影响需要你在代码里特别注意第一被基础类加载器加载的类改动后不会触发重启。最常见的例子是你改了pom.xml里的依赖版本或者修改了一个被其他 jar 依赖的本地模块devtools 不会因为这些变化自动重启。遇到这种情况你手动重启一下就好不要在那儿傻等。第二类加载器不兼容问题。因为你的类和第三方的类分别由不同类加载器加载如果代码里出现自己写的类实现第三方接口并把这个实现类的实例传给第三方框架的情况某些极端场景下会抛ClassCastException。因为同一个接口在基础类加载器里有一个实例在你的类加载器里又有一份两边类型不一致。我在项目里遇到过几次主要集中在自定义序列化器和某些 ORM 框架的 SPI 扩展上。解决方法是把出问题的类挪到一个由基础类加载器加载的模块中或者用spring.devtools.restart.exclude排除掉它们。第三静态资源默认不触发重启。默认情况下 devtools 只监控 classpath 下的.class文件变更static目录下的 CSS、JS、图片不在监控范围内。这其实是合理的因为前端资源改了直接刷新浏览器就行没必要重启后端。但如果你在改 Thymeleaf 模板模板文件在templates下有两个方案一是把模板文件也加入监控触发重启但这会拖慢节奏二是配合模板引擎的缓存关闭让模板文件修改立即生效。后面我会专门讲这个配置。这套类加载器机制还有一个隐藏价值它让重启和重新加载配置可以分开控制。比如你改了application.ymldevtools 默认会触发一次重启但如果你只是改了环境变量或某些外部配置可以通过spring.devtools.restart.enabledfalse单独关掉重启只保留配置加载。这个细粒度控制在某些运维场景下挺有用。3. 从零配置 devtools一步步搭出一个真正好用的开发环境3.1 基础依赖引入与作用域限制Maven 项目引入 devtools 很简单一个依赖的事dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId scoperuntime/scope optionaltrue/optional /dependency这里有两个细节值得展开。scope设为runtime是因为 devtools 只在运行时需要打包部署时没必要把它打进最终的 jar 里虽然就算打进去也不会主动生效后面我会说为什么optional设为true是为了避免通过依赖传递把这玩意带到其他模块里。我做多模块项目时吃过亏A 模块引入了 devtools 但没有设 optional结果所有依赖 A 的子模块都带着 devtools排查了半天才发现是传递依赖搞的鬼。Gradle 项目的话对应写法是developmentOnly(org.springframework.boot:spring-boot-devtools)developmentOnly这个配置是 Gradle 专门为 devtools 设计的效果和 Maven 的 runtime optional 类似只在本地开发环境生效。3.2 IDE 侧的关键配置IDEA 自动编译和 Build 设置只加依赖不配 IDEdevtools 不会自动工作。IDEA 里默认的构建和运行是两个独立动作如果你只点运行按钮IDEA 根本不会自动重新编译修改过的.java文件devtools 也就检测不到任何变化。正确配置分两步。第一步打开设置找到Build, Execution, Deployment - Compiler勾选Build project automatically自动构建项目。第二步在高级设置macOS 上是Preferences - Advanced SettingsWindows 上是Settings - Advanced Settings里找到Allow auto-make to start even if developed application is currently running允许自动构建在应用运行期间也生效把它勾上。第二步是最多人漏掉的不勾的话应用运行期间修改代码 IDEA 也不会自动编译devtools 依然感知不到变化。Eclipse 用户的话项目设置里勾选Build automatically即可Eclipse 会自动编译修改的文件devtools 检测到后触发重启。这一步配完你的开发流程就变成了改代码 - 切换回 IDEA 窗口或直接悬挂- IDEA 自动编译 - devtools 检测到 class 文件变化 - 自动重启 - 刷新页面。从改完代码到应用重新可用中间你手都不用动。3.3 必须掌握的 application.yml 配置项devtools 在application.yml里暴露了一批配置项我挑几个实际开发中最常用的说一下完整的配置清单以官方文档为准。spring: devtools: restart: enabled: true # 是否开启自动重启默认 true exclude: static/**,public/** # 排除不需要触发重启的目录 additional-paths: src/main/java # 额外监控路径 trigger-file: .trigger # 使用触发文件模式后面细说 livereload: enabled: true # 是否开启 LiveReload默认 truetrigger-file这个配置值得单独讲。当你开着 devtools 自动重启改一个文件重启一次有些场景会很烦——你连续改了五个文件devtools 就会连续重启五次每次都要等浪费的等待时间成倍增加。触发文件模式就是解决这个问题的你先设置一个触发文件比如项目根目录下的.trigger文件devtools 会监控这个文件只有当这个文件的内容发生变化时才触发重启。实操中你可以在根目录创建.trigger文件改完一批代码后往里面随便加一行字比如// restartdevtools 检测到变化统一重启一次。如果你项目里没人用过这个模式第一次用你会觉得之前都在裸奔。3.4 JSON 和模板引擎的缓存问题devtools 本质上只管类加载和重启但 Spring Boot 的很多组件默认有缓存这些缓存不关的话你改了配置或模板重启了也没用。最典型的是 Thymeleaf 模板缓存。Spring Boot 默认在非 web 环境下不缓存模板但在打包运行时会有缓存策略。开发时你需要把缓存显式关掉spring: thymeleaf: cache: falseFreeMarker 同理spring.freemarker.cachefalse。这俩是使用率最高的模板引擎几乎每个用 Spring Boot 做页面渲染的开发者都会踩到这个坑后端代码改了能自动重启但页面模板改了刷新还是旧内容原因就是模板引擎自身的缓存跟 devtools 没有关系。还有 JSON 的序列化配置如果你自定义了 Jackson 的序列化器或反序列化器改了之后也要注意 Jackson 模块的缓存情况。不过大多数项目不会太频繁地改序列化逻辑这个相对冷门。3.5 第一次启动 devtools 应该看到的日志标志引入配置完成后启动应用观察日志里有没有这样一行RestartClassLoader: 2024-01-15 10:23:45.123 INFO ... Restarting application如果看到类似Starting Application...之后紧接着Restarted main application之类的输出不同 Spring Boot 版本日志格式略有差异说明 devtools 已经接管了应用生命周期。另外默认情况下 devtools 启动时会显示一个独立的横幅Banner和应用自己的启动横幅不同这是判断 devtools 是否生效的一个快速标志。如果你改了代码等了几秒日志里出现了类似Restarted main application的记录说明自动重启链路已经跑通。没看到的话按下一章的排查链路来走。4. 热部署不生效从现象到根因的完整排查链路说实话devtools 报错的情况反而好办最恶心的是加了依赖、配了 IDE改代码就是不重启也不报错。这种沉默故障的排查要按顺序来别乱试不然越改越乱。4.1 排查第一步确认 devtools 是否真的在运行先看启动日志有没有RestartClassLoader相关的输出。Spring Boot 2.x 之前的版本devtools 默认会在启动时打印一个Starting Application...的日志并用独立的线程重启应用所以日志里会出现两次应用启动记录。如果整个日志只有一次启动记录说明 devtools 根本没生效。一种常见原因是你用java -jar直接运行了打包好的 jar。devtools 官方设计上就是生产环境自动禁用的Spring Boot 里通过spring.devtools.restart.enabled的默认赋值逻辑基于启动方式判断决定了这一点从 IDE 启动或使用spring-boot:run命令时它生效从打包 jar 启动时它自动失效。所以如果你在 IDE 里直接跑 main 方法devtools 应该生效如果你先mvn package再java -jar app.jardevtools 大概率不工作这是符合预期的。排查动作检查启动方式。IDE 运行 main 方法、mvn spring-boot:run、gradle bootRun这三种方式devtools 都会生效。其他方式比如自定义的启动脚本、容器内启动需要检查环境变量。4.2 排查第二步IDE 自动编译和构建事件链这是最常见的坑。devtools 触发自动重启的前提是 classpath 下的.class文件发生了变化。IDEA 里如果你没开自动编译改完代码的 .java 文件根本不会变成新的 .class 文件devtools 无事可做。检查两处设置Build, Execution, Deployment - Compiler下的Build project automaticallyAdvanced Settings里的Allow auto-make to start even if developed application is currently running第二个设置尤其重要很多人的自动编译开了但高级设置没勾应用运行期间 IDEA 就是不编译。这个选项在 IDEA 2020.2 及之后版本默认是关闭的我见过好几个同事在改代码 - 等重启 - 没反应 - 手动重启这个循环里浪费时间最后都是这个选项的问题。另外一个隐藏因素如果你用的构建工具是 Maven 或 Gradle并且习惯用它们的命令来启动应用mvn spring-boot:run那么文件变化能否被检测还取决于构建工具的监听机制。Maven 的spring-boot:run默认会监控target/classes目录所以只要 IDE 或者mvn compile产生了新的 .class 文件devtools 就能感知。但如果你用的是 IDEA 自带的构建注意 IDEA 默认构建输出目录和 Maven 的target/classes可能不是同一个IDEA 默认输出到classes目录。这会导致一个情况IDEA 自动编译了但 class 文件输出到了 A 目录devtools 监控的是 B 目录永远检测不到变化。解决办法是统一构建输出目录让 IDEA 使用 Maven 的target/classes作为输出路径或者直接统一用 Maven/Gradle 来运行应用。4.3 排查第三步日志级别泄露的蛛丝马迹打开 debug 日志再试一次触发重启命令很简单logging: level: org.springframework.boot.devtools: DEBUGdevtools 在 debug 级别下会输出类加载器的监控活动比如哪些路径被监控、检测到了哪些变化、为什么没有触发重启。这些信息比盲猜高效得多。有一个印象深刻的案例项目里用了spring-boot-devtools但一直不生效开了 debug 才发现监控路径是target/classes但项目实际把编译输出重定向到了build/classes/java/main某个 Gradle 插件干的devtools 默认的监控路径根本没指向正确的地方。通过spring.devtools.restart.additional-paths把 Build 输出目录加进去就解决了。4.4 排查第四步构建工具和 IDE 的互相打架如果你既用 IDE 的自动编译又用 Maven/Gradle 的增量编译偶尔会遇到改一次代码触发了两次重启或者重启到一半又中断的现象。本质上是两个编译进程在竞争写同一个 class 文件class 文件在短时间内被反复替换devtools 多次检测到变化导致多次重启。这类问题的解决方向是职责分离IDE 只负责写代码和启动应用编译交给 Maven/Gradle 的某个具体命令来触发或者反过来IDE 全权负责编译Maven/Gradle 只做依赖管理。不要在运行期间同时让两个构建工具频繁操作同一个目录。4.5 一个特殊的坑JDK 版本和编译器参数devtools 的自动重启依赖 Java 的类文件监听原理是轮询 classpath 下文件的lastModified时间戳。如果你用了某些文件系统比如网络磁盘、容器挂载卷时间戳的更新粒度可能不够精细导致 devtools 检测不到变化。这个在本地开发很少见但如果你把代码放在 Docker 挂载的目录或者 SMB 网络盘上开发就有可能遇到改了代码不重启的情况。方案是改用spring.devtools.restart.poll-interval和spring.devtools.restart.quiet-period这两个参数调整轮询策略默认分别是 1 秒和 400 毫秒把轮询间隔调短、静默期调长避免因时间戳粒度问题漏掉变化。5. 进阶玩法远程热部署、LiveReload 与容器环境的取舍5.1 Remote Devtools远程环境的热部署边界devtools 提供了一种远程应用模式官方叫 Remote Debug / Remote Restart。原理很简单在部署了应用的机器上开启一个服务端口本地 IDE 连接过去本地改代码远程机器上自动重启。配置方式是在远程启动参数里加上spring-boot的 devtools 远程协议端口-Dspring.devtools.remote.secretmysecret然后本地 IDE 里配置一个 Remote 类型的启动项连接到远程端口。这类方案适合开发阶段就把应用部署到远程测试机的场景比如某些公司要求所有联调环境都在服务器上。但我个人不太推荐在生产或准生产环境用这个——安全风险很高secret一旦泄露等于把应用重启权限交出去。而且远程网络不稳定的情况下大文件变动触发重启的效率远不如本地。如果你有远程开发需求优先考虑 IDE 的远程开发套件那套方案走的是远程文件同步加远程启动体验比 devtools 的 Remote 模式好得多。另外提一句如果你在用 Spring Cloud 全家桶做微服务开发记得 devtools 只对当前进程生效。也就是说你同时起了三个微服务实例改了一个模块只有一个实例会重启其他实例不会自动感知。微服务场景下热部署要整体设计往往要配合消息总线的配置刷新机制。5.2 LiveReload页面级别的免刷新体验devtools 内置了一个 Livereload 服务器默认跑在35729端口。配合浏览器的 LiveReload 插件可以实现后端代码改完浏览器自动刷新页面的效果。很多年前这是一个很惊艳的功能现在大部分人的开发流程变成了前端工程Vite/Webpack自带的 HMR后端页面模板Thymeleaf 等的场景才用到它。我的体验是它对纯后端 API 开发没什么用主要是渲染页面的时候配合使用可以省去手动刷新浏览器的动作。注意如果你用了 Spring Cloud Gateway 这类反向代理LiveReload 的端口需要额外透配不然刷新脚本连不上。5.3 Docker 容器里能做热部署吗先给结论能但有条件。devtools 的原理决定了它要监控 classpath 下的文件变化而 Docker 容器里如果代码是打进镜像里的运行中的容器根本不会感知宿主机上源码的变化所以镜像化部署之后 devtools 基本等于摆设。常见做法是开发阶段用 Docker 做环境隔离比如把 MySQL、Redis 放容器里而 Spring Boot 应用仍然在本地跑或者用 Docker Compose 把源码目录用 volume 挂载进容器target/classes目录也挂载进去这样本地编译产生的 class 文件变化能透过挂载卷被容器里的 devtools 感知到。这种方案可行但有两件事要注意挂载卷在宿主机和容器之间的文件时间戳同步跨平台时比如 Mac 的 Docker Desktop 走 gRPC-FUSE偶有延迟容器里 JDK 版本、文件权限和本地不完全一致少数情况下重新编译的 class 文件在容器里加载会报奇奇怪怪的异常所以我的个人建议是本地开发能跑就本地跑Docker 只做依赖服务的隔离真要全容器化开发优先考虑云开发环境那一套。5.4 项目变大后的替代方案JRebel 是不是智商税当项目规模上来之后devtools 的重启策略还是会越来越慢。因为它说到底还是重启了 Spring 上下文只是省了第三方类的加载时间。一个几千个 Bean 的大项目devtools 重启花个 10 秒很正常。这时候有些人会切换到 JRebel。JRebel 的定位是真正的热替换——它不重启 Spring 上下文而是在运行中的 JVM 里替换类定义连 Spring 容器的 Bean 都给你原地换掉。从体验上说JRebel 确实快而且支持字段新增、方法签名变更这类 devtools 完全做不到的操作。代价是它收费而且引入字节码增强后偶尔会和某些框架比如一些 Agent 类监控工具有兼容问题。从我实际使用的感受来说项目在 2000 个 Bean 以内devtools 的体验是完全够用的超过这个量级、或者热部署改动频繁且每次都等不了那 5 秒的可以考虑 JRebel。但我建议先优化自己的开发流程——比如把大项目拆成模块用 devtools 的触发文件模式批量触发而不是频繁地单个文件触发重启。很多重启太慢的痛点其实可以通过流程优化解决没必要一上来就上付费方案。5.5 关于多模块项目的特殊提醒多模块的 Maven/Gradle 项目里devtools 的监控范围默认是当前模块加它依赖的模块。这里有个容易出问题的点如果你改了parent模块或某个公共模块的代码而这个模块被打包成 jar 被当前应用引用devtools 默认不监控它。需要把公共模块的构建输出目录加进spring.devtools.restart.additional-paths里改完公共模块后还要手动 install 一下让新版本进入本地仓库应用才会拉取到新 jar 并重启。这个流程稍微繁琐但理解了类加载器机制后就很自然devtools 监控的是 classpath 下的 .class 文件公共模块的 .class 文件在它的本地构建目录里不在应用的 classpath 下除非显式把它加进监控路径。6. 避坑清单那些文档里没写的实战细节写到最后把这几年用 devtools 积攒的经验和教训整理成一个清单都是踩过坑之后才明白的东西dependencies 里不要漏掉 optional。传递依赖带上 devtools会在下游模块里造成很多莫名其妙的自动重启行为排查起来非常费劲。不要在生产环境碰 devtools。它默认在java -jar启动时是禁用的但如果你用某些方式手动改了这个开关一定要确保生产环境是关闭的。devtools 带来的重启延迟在生产流量下是灾难性的而且它的自动重启逻辑在集群环境下是失控的每个副本各自重启流量就会抖动。如果业务确实需要不停机更新那是发布系统的问题不是热部署的问题。改配置文件触发重启这件事有一个例外application.yml本身改变时devtools 重启后会重新加载配置但spring-boot的某些配置项比如 datasource 的 url在运行时修改并不会真正生效只会悄悄报错或者保持旧连接。如果你改了spring.datasource.*期望热生效大概率会失望。数据库连接、线程池这类底层资源改动后必须全量重启。静态资源的处理策略开发阶段推荐把静态资源排除出重启监控范围exclude: static/**然后配合前端工程的 HMR 或者 LiveReload 来刷新页面。这样后端改代码触发重启时不会因为 static 目录下的文件也被检测到而多发一次无谓重启。JRebel 和 devtools 不要同时开。同一个人改了代码先被 JRebel 处理一遍又被 devtools 重启一遍结果是系统状态混乱。两套方案选一套。网络盘和容器挂载目录下的项目先确认文件时间戳粒度。devtools 默认的轮询逻辑依赖文件修改时间某些文件系统的时间戳精度粗糙常见于跨平台的挂载卷会导致检测不到变化。遇到改了不重启的诡异场景先怀疑文件系统再怀疑配置。一个容易被忽略的细节改类名或移动类文件。如果发生了文件的删除或重命名devtools 的重启类加载器会重新扫描 classpath这个过程比普通改动触发重启稍慢。遇到项目文件大量增删的场景准备好多等几秒不要以为 devtools 坏了。IDEA 里同时开了多个 Spring Boot 实例时devtools 的 LiveReload 端口会冲突。默认都是 35729第二个实例会报端口占用。要么关闭多余实例的 livereload要么显式配置不同端口。启动参数里加-Dspring.devtools.restart.enabledfalse可以临时关掉重启。有时候你只是想改一个静态资源看效果不想让 devtools 重启后端这时候直接在启动参数里把这个开关关了只保留 LiveReload页面照样自动刷新后端纹丝不动。这个用法在只想调前端样式的时候特别顺手。说到底热部署解决的不只是省几秒钟等待它改变的是你的开发心流。改一次代码要等一次重启你就会下意识避免改代码而这种回避带来的代码质量损失才是真正巨大的。把热部署环境调好让自己敢改代码、愿意改代码这才是我推荐这件事的核心原因。