問題：

最近在使用新框架SpringBoot + shiro + spring-data-jpa時，為了體驗下spring自帶的熱部署工具的便捷，于是引入了

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <!-- optional=true,依賴不會傳遞，該項目依賴devtools；之后依賴myboot項目的項目如果想要使用devtools，需要重新引入 --> <optional>true</optional> </dependency>

在起初并沒遇到什么問題，當使用shiro的session管理，而且用的sessionDao是redis實現(xiàn)的，然后再使用Session存取屬性時，發(fā)現(xiàn)存進去的屬性，再取出來后，就會出現(xiàn)類型轉換異常ClassCastException

分析：

然后自己寫了一大推單元測試模擬就是沒問題，后來突然意識到會不會是因為ClassLoader不同導致的類型轉換異常呢，然后注意了下項目啟動時加載項目中的類使用的加載器都是

org.springframework.boot.devtools.restart.classloader.RestartClassLoader

而從shiro session 取出來的對象（從redis中取出經(jīng)過反序列化）的類加載器都是

sun.misc.Launcher.AppClassLoader

很明顯會導致類型轉換異常，原來Spring的dev-tools為了實現(xiàn)重新裝載class自己實現(xiàn)了一個類加載器，來加載項目中會改變的類，方便重啟時將新改動的內(nèi)容更新進來，其實其中官方文檔中是有做說明的：

By default, any open project in your IDE will be loaded using the “restart” classloader, and any regular .jar file will be loaded using the “base” classloader. If you work on a multi-module project, and not each module is imported into your IDE, you may need to customize things. To do this you can create a META-INF/spring-devtools.properties file. The spring-devtools.properties file can contain restart.exclude. and restart.include. prefixed properties. The include elements are items that should be pulled up into the “restart” classloader, and the exclude elements are items that should be pushed down into the “base” classloader. The value of the property is a regex pattern that will be applied to the classpath.

解決：

方案一、解決方案就是在resources目錄下面創(chuàng)建META-INF文件夾，然后創(chuàng)建spring-devtools.properties文件，文件加上類似下面的配置：

restart.exclude.companycommonlibs=/mycorp-common-[w-]+.jar restart.include.projectcommon=/mycorp-myproj-[w-]+.jar

All property keys must be unique. As long as a property starts with restart.include. or restart.exclude. it will be considered. All META-INF/spring-devtools.properties from the classpath will be loaded. You can package files inside your project, or in the libraries that the project consumes.

方案二、不使用spring-boot-devtools

針對方案一作一個詳細的案例進行分析說明，以及解決問題

首先準備一個jar包，里面包含序列化以及反序列化的功能。

并打包，在springboot項目中引入

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId></dependency><!-- 這個包是我自己創(chuàng)建的序列化以及反序列化工具包 --><dependency> <groupId>com.example</groupId> <artifactId>devtools-serialization</artifactId> <version>1.0-SNAPSHOT</version></dependency>

簡單的配置下springboot項目，并模擬使用jar中的序列化工具類進行處理對象如下

@SpringBootApplicationpublic class PortalApplication { public static void main(String[] args) throws Exception { ConfigurableApplicationContext context = SpringApplication.run(PortalApplication.class, args); DemoBean demoBean = new DemoBean(); SerializationUtils.serialize(demoBean); Object deserialize = SerializationUtils.deserialize(); System.out.println(PortalApplication.class.getClassLoader()); //這里對象引用是Object類型 System.out.println(deserialize); System.out.println(deserialize.getClass().getClassLoader()); context.getBeanFactory().destroySingletons(); }}

如上，是不會報錯的，因為Object是bootstrap引導類加載器加載的，因此不會產(chǎn)生任何問題，

但是如果改成下面這樣

//... public static void main(String[] args) throws Exception { ConfigurableApplicationContext context = SpringApplication.run(PortalApplication.class, args); DemoBean demoBean = new DemoBean(); SerializationUtils.serialize(demoBean); Object deserialize = SerializationUtils.deserialize(); System.out.println(PortalApplication.class.getClassLoader()); //注意這里進行了一次類型強轉 System.out.println((DemoBean)deserialize); System.out.println(deserialize.getClass().getClassLoader()); context.getBeanFactory().destroySingletons(); } //...

結果是會拋出：

Exception in thread 'restartedMain' java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.springframework.boot.devtools.restart.RestartLauncher.run(RestartLauncher.java:49) Caused by: java.lang.ClassCastException: com.sample.serial.DemoBean cannot be cast to com.sample.serial.DemoBean at com.sample.PortalApplication.main(PortalApplication.java:27) ... 5 more

而觀察上面輸出的ClassLoader信息會發(fā)現(xiàn)分別為

org.springframework.boot.devtools.restart.classloader.RestartClassLoader@63059d5a sun.misc.Launcher$AppClassLoader@18b4aac2

這就是為什么會明明沒問題，卻仍然拋了個ClassCastException的根源所在。

那么如何解決這個問題呢？

將輸出的ClassLoader信息保持一致即可，要么都是RestartClassLoader要么都是

AppClassLoader

這里參考spring官方文檔給出的配置方法進行處理。

在resources下創(chuàng)建META-INF/spring-devtools.properties

如圖：

下一步在spring-devtools.properties添加配置

restart.include.projectcommon=/devtools-serialization-[w.-]+.jar

注意這里我需要包含的jar包名稱為devtools-serialization-1.0-SNAPSHOT.jar

配置的key以restart.include.開頭即可

restart.include.*

value 為一個正則表達式

下面再次運行程序查看效果：

沒有異常產(chǎn)生

控制臺輸出classLoader信息為

org.springframework.boot.devtools.restart.classloader.RestartClassLoader@1d9fbdd4 DemoBean{age=null, name=’null’} org.springframework.boot.devtools.restart.classloader.RestartClassLoader@1d9fbdd4

問題完美解決。

補充知識：Springboot+devtools配置熱部署

Spring Boot提供了spring-boot-devtools這個模塊來使應用支持熱部署，可以提高開發(fā)者的開發(fā)效率，無需手動重啟Spring Boot應用就能實現(xiàn)自動加載，之前寫了一篇可以自動加載springboot靜態(tài)文件的，這次的只需要在原來的基礎上再加一些配置即可實現(xiàn)springboot工程的熱部署，步驟如下：

1、pom文件增加依賴：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> </dependency></dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration><fork>true</fork> <!--重要--> </configuration> </plugin> </plugins></build>

2、yml文件中添加配置使其生效：

# devtoolsdebug: truespring: devtools: restart: enabled: true #設置開啟熱部署 freemarker: cache: false #頁面不加載緩存，修改即時生效

3、快捷鍵：Ctrl+Alt+S

4、快捷鍵：Ctrl+Shift+A,輸入Registry,點擊進入勾選：

以上這篇解決SpringBoot使用devtools導致的類型轉換異常問題就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持好吧啦網(wǎng)。