Spring boot热部署导致的Druid dataSorce already closed at xxxxx

Error querying database. Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is com.alibaba.druid.pool.DataSourceClosedException: dataSource already closed at xxxx

服务里有使用kafka做消费者，前不久因为总是重启麻烦，就在pom里加了热部署的包

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-devtoos</artifactId>

    <scope>runtime</scope>

</dependency>

自动编译之后，一旦跑kafka，就会抛出Druid dataSorce already closed at xxxxx的异常信息。

出了问题下意识就想，是不是哪里有手动关闭导致的，查了提交记录，并没有，这个想法被排除掉。

然后在看输出的错误信息时，关闭的时间都是14:23，翻之前的日志，在14:23本地打印的信息正好是在重新编译的时间。直接重启服务，恢复正常。初步定位，是热部署的问题。

删掉热部署的配置，一切正常，报错信息并没有再出现。

----------------------------

开始搜索大法，查找原因

官方的推荐依赖

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

scope的5种类型

默认是compile，表示跟项目一起编译

provided表示打包的时候可以不打进去，其他的Web Container会提供

runtime表示不会和当前项目一起编译

system从参与度来说，也provided相同，不过被依赖项不会从maven仓库抓，而是从本地文件系统拿，一定需要配合systemPath属性使用

test表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行

optional的含义

Optional定义后，该依赖只能在本项目中传递，不会传递到引用该项目的父项目中，父项目需要主动引用该依赖才行。

Exclusions则是主动排除子项目传递过来的依赖。

在druid的git问题收集里找到同样的问题，并没有解决

热部署的原理是重写了类加载器

当我们修改了classpath下的文件（包括类文件、属性文件、页面等）时，会重新启动应用（由于其采用的双类加载器机制，这个启动会非常快，另外也可以选择使用jrebel）。

spring-boot-devtools使用了两个类加载器来实现重启（restart）机制：

base类加载器（base ClassLoader）, restart类加载器（restart ClassLoader）。

base ClassLoader：用于加载不会改变的jar（eg.第三方依赖的jar） restart ClassLoader：用于加载我们正在开发的jar（eg.整个项目里我们自己编写的类）。当应用重启后，原先的restart ClassLoader被丢掉、重新new一个restart ClassLoader来加载这些修改过的东西，而base ClassLoader却不需要动一下。这就是devtools重启速度快的原因。

猜测，类加载器重新加载类的时候并没有重新加载数据库连接池，导致这个问题。

最后，只能删掉maven中热部署的配置，问题并没有解决。