目前在做springboot項(xiàng)目的shiro session redis共享功能。但是有一個(gè)對(duì)象我把它放到redis中之后再取出來(lái)就會(huì)出現(xiàn)類型不匹配的異常

AuthorizationUser user = (AuthorizationUser) cache.getSuper(key);

異常信息：

java.lang.ClassCastException: com.ch.evaluation.auth.shiro.entity.AuthorizationUser cannot be cast to com.ch.evaluation.auth.shiro.entity.AuthorizationUser

通過(guò)debug看到他們的類信息是一樣的

難道只是看起來(lái)一樣么？我來(lái)判斷一下

結(jié)果是false ,

那么我們知道JVM判斷兩個(gè)類對(duì)象是否相同的依據(jù):一是類全稱;一個(gè)是類加載器

既然他倆的類全稱一樣，那么問(wèn)題肯定就出在了類加載器上了

我們可以Debug看一下他倆的類加載器

果然不出所料，他倆的類加載器是不同的！

那么是什么原因?qū)е滤念惣虞d器不一樣呢？

　　大家都知道虛擬機(jī)的默認(rèn)類加載機(jī)制是通過(guò)雙親委派實(shí)現(xiàn)的。springboot為了實(shí)現(xiàn)程序動(dòng)態(tài)性（比如：代碼熱替換、模塊熱部署等，白話講就是類文件修改后容器不重啟），“破壞或犧牲” 了雙親委派模型。springboot通過(guò)強(qiáng)行干預(yù)-- “截獲”了用戶自定義類的加載（由jvm的加載器AppClassLoader變?yōu)閟pringboot自定義的加載器RestartClassLoader，一旦發(fā)現(xiàn)類路徑下有文件的修改，springboot中的spring-boot-devtools模塊會(huì)立馬丟棄原來(lái)的類文件及類加載器，重新生成新的類加載器來(lái)加載新的類文件，從而實(shí)現(xiàn)熱部署。比較流行的OSGI也能實(shí)現(xiàn)熱部署）。

既然源頭因熱部署而起，所以只要想辦法關(guān)掉springboot的熱部署即可。

<方案一> 通過(guò)卸掉springboot的熱部署模塊spring-boot-devtools來(lái)實(shí)現(xiàn)

在pom中注釋掉springboot的spring-boot-devtools

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

<方案二>如果不想卸掉spring-boot-devtools模塊也可禁用部署功能

讀者也可以在application.properties設(shè)置禁用屬性，但它的作用域只發(fā)生在當(dāng)前模塊，如果你的項(xiàng)目牽扯到多個(gè)模塊，最好通過(guò)上面的方式在整個(gè)運(yùn)行系統(tǒng)的級(jí)別禁用，以免出現(xiàn)多個(gè)模塊之間實(shí)現(xiàn)類文件調(diào)用時(shí)類加載器不一致的問(wèn)題。

<方案三>既然是類加載器的問(wèn)題也可使用Spring的ConfigurableObjectInputStream配合Thread.currentThread().getContextClassLoader() 來(lái)使用。

?

轉(zhuǎn)載于:https://www.cnblogs.com/UncleWang001/p/10063172.html

總結(jié)

以上是生活随笔為你收集整理的对象反序列化出现类型不匹配的情况(spring-boot-devtools)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。