SpringBoot魔法堂：应用热部署实践与原理浅析

前言

后端开发的同学想必每天都在重复经历着修改代码、执行代码编译，等待……重启Tomcat服务，等待……最后测试发现还是有bug，然后上述流程再来一遍（我听不见）
能不能像前端开发的同学那样，修改代码保存文件后自动编译、重新加载应用呢？Spring Boot给了我们一个大大的Yes！
本文我们就一起来探索Spring Boot的热部署功能提升开发效率吧！

长话短说

热部署作为开发阶段的特性，由spring-boot-devtools模块提供，用于在修改类、配置文件和页面等静态资源后，自动编译Spring Boot应用和加载应用和页面静态资源，从而提高开发流程自动化程度提升开发效率。
那么第一步当然是在pom.xml中添加配置：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-devtools</artifactId>
  <option>true</option>
</dependency>

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <configuration>
        <fork>true</fork> <!-- 默认值为false，必须设置为true才能启用热部署功能（具体原因请见下文） -->
      </configuration>
    </plugin>
  </plugins>
</build>

静态资源热部署

对于HTML页面、图片、CSS样式文件这些显然不需要编译的静态资源，Spring Boot Devtools模块通过内置的livereload服务端和浏览器的LiveReload插件共同实现热部署。

1. 服务端配置

spring:
  devtools:
    livereload:
      enabled: true # 启用LiveReload服务端
      port: 35729 # LiveReload服务端口

默认仅触发LiveReload事件的默认路径如下： /META-INF/maven,/META-INF/resources,/resources,/static,/public和/templates。

1. 浏览器配置
   无论时FireFox还是Chrome都有相应的LiveReload插件，按步骤安装就可以了。

Java类资源热部署

Spring Boot Devtools模块是通过监听Java类资源变化触发应用热部署，请注意这里监听的是Java类资源而不是Java源代码文件，那么什么是Java类资源**呢？其实就是.class文件。
这样从保存Java源代码文件到Spring Boot Devtools监听到Java类资源变化之间，就有一道不可逾越的鸿沟了。我们必须通过额外手段填平：

1. 手动方式：修改Java源代码文件后，执行mvn compile
2. 自动方式：配置IDEA监听Java源代码文件变化，触发重新编译
   2.1. 右键点击SpringBootApplication入口类文件，并点击Create XXXX.main()，创建Application类型的Configuration；
   2.2. 勾选File/Settings/Compiler/Build Project automatically；
   2.3. 按ctrl+shift+alt+/，然后选择Registry并勾选Compiler autoMake allow when app running；
   2.4. 通过IDEA左上角绿色的运行按钮启动Spring Boot应用，然后修改Java源代码文件后IDEA会自动重新编译项目，从而触发Spring Boot Devtools热部署。

更多配置配置项

spring:
  devtools:
  restart:
    enabled: true # 启用热部署
    exclude: main/static/** # 除默认路径外，添加文件变化不触发热部署的路径列表，多个路径之间通过逗号分隔。
    additional: assets/** # 添加文件变化会触发热部署的路径列表，多个路径之间通过逗号分隔。
    additional-exclude: assets/public/** # 设置additional属性指定的路径下某些路径的文件变化，不触发热部署，多个路径之间通过逗号分隔。

默认不触发热部署的路径有：/META-INF/maven,/META-INF/resources,/resources,/static,/public和/templates。

除了通过yml文件配置是否启用热部署功能外，还可以通过环境变量设置。在SpringBootApplication入口方法中加入

System.setProperty("spring.devtools.restart.enabled", "false");
SpringApplication.run(MyApp.class, args);

疑难解答

1. 在IDEA中修改文件后报 Maven Resource Compiler: Maven project configuration required for module 'lkm-api' isn't available. Compilation of Maven projects is supported only if build is started from an IDE.
   答：请使用IDEA那个绿色的运行按钮启动Spring Boot应用。
2. 在IDEA中修改文件后没有反应
   答：请稍等数秒自然会触发重新编译和热部署的。

为什么是热部署而不是热替换呢？

开发过React或Vue的同学对热替换应该不陌生吧，可以粗线条地理解为将应用以比文件更细粒度的模块或函数来组织，当源代码发生变化时仅仅替换发生变化的模块或函数以及依赖它们的模块或函数，通过最小化变更达到快速更新应用状态。
而Spring Boot Devtools并没有做成像React和Vue的开发工具那么细粒度的更新，而是采取通过基类加载器和重启类加载器两个类加载器来实现热部署：

1. 基类加载器，用于加载第三方依赖等开发阶段不经常发生变化的Java类资源。
2. 重启类加载器，用于加载当前项目的Java类资源。若当前项目的Java类资源发生变化时，正在运行的重启类加载器会被丢弃，并另外创建一个重启类加载器并加载最新的Java类资源。

为什么pom.xml文件中的spring-boot-maven-plugin要设置为独立JVM进程运行呢（<fork>true</fork>）？

默认情况下<fork>false</fork>表示Maven采用运行自身的JVM虚拟机运行插件，而通过<fork>true</fork>则告知Maven启动一个新的JVM虚拟机进程运行插件。
那么为什么要耗费资源启动新JVM虚拟机执行插件呢？直接运行不香吗？

场景1——使用不同的JDK运行插件

执行mvn -v会显示当前Maven运行的JDK版本信息，假设为JDK1.8且编码方式为UTF-8。
由于Maven 3.8.1必须运行在JDK1.8以上，而项目只能在JDK1.6上编译运行，因此需要通过如下方式执行插件：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.8.1</version>
  <configuration>
    <fork>true</fork>
    <!-- 指定JDK家目录，默认为环境变量PATH中的路径 -->
    <executable>/path/to/jdk1.6</executable>
    <compilerVersion>1.3</compilerVersion>
  </configuration>
</plugin>

场景2——采用不同的JVM配置运行插件

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.8.1</version>
  <configuration>
      <fork>true</fork>
      <meminitial>128m</meminitial>
      <maxmem>1024m</maxmem>
      <compilerArgs>
        <arg>-XX:MaxPermSize=256m</arg>
      </compilerArgs>
  </configuration>
</plugin>

场景3——插件需要特定的JVM配置来运行

像spring-boot-maven-plugin那样在启用spring-boot-devtools模块时需要特定JVM配置来运行，并且运行途中还会对重启类加载器惨下杀手的，自然也要创建新的JVM虚拟机进程来运行才可以了。

总结

Spring Boot不单单通过约定由于配置的原则简化了过去Spring MVC那些繁琐的配置文件，还提供各种显著提升开发效率的自动化工具，而spring-boot-devtools就是其中一个。
倘若你所在的团队还没用上Spring Boot那么是不是就无法享受这份便捷呢？我想JRebel IDEA插件应该是你需要的:)

转载请注明来自：https://www.cnblogs.com/fsjohnhuang/p/14136491.html —— 肥仔John