目录
异常信息
同一个类转换出现ClassCastException异常
java.lang.ClassCastException: com.guazi.aftermarket.dubbo.crm.mining.entity.QueryNewCustomerInfoEntity cannot be cast to com.guazi.aftermarket.dubbo.crm.mining.entity.QueryNewCustomerInfoEntity
at com.alibaba.fastjson.serializer.ASMSerializer_3_QueryNewCustomerInfoEntity.write(Unknown Source)
at com.alibaba.fastjson.serializer.JSONSerializer.writeWithFieldName(JSONSerializer.java:310)
at com.alibaba.fastjson.serializer.ASMSerializer_2_DubboResult.write(Unknown Source)
at com.alibaba.fastjson.serializer.JSONSerializer.write(JSONSerializer.java:281)
at com.alibaba.fastjson.JSON.toJSONString(JSON.java:673)
at com.alibaba.fastjson.JSON.toJSONString(JSON.java:611)
at com.alibaba.fastjson.JSON.toJSONString(JSON.java:576)
...
根本原因
类加载器不一致
Java中,判断是否为同一个类的条件:类的全名称+类加载器,由于类的全名称相同,所以一定是类加载器不一致导致的类型转换
原因
使用 spring-boot-devtools 时,很多"应用类"是由spring提供的org.springframework.boot.devtools.restart.classloader.RestartClassLoader加载,而不是以前的sun.misc.Launcher$AppClassLoader,关于Java的类加载器可见:反射
使用 spring-boot-devtools 时,日志打印出类加载器如下:
注释掉 spring-boot-devtools 时,打印出类加载器如下
spring-boot-devtools
是什么?
spring为开发者提供了一个名为spring-boot-devtools的模块来使Spring Boot应用支持热部署,提高开发者的开发效率,无需手动重启Spring Boot应用
原理?
spring boot使用两个classloader:不改变的类(如第三方jar)由base类加载器加载,正在开发的类由restart类加载器加载。应用重启时,restart类加载器被扔掉重建,而base类加载器不变,这种方法意味着应用程序重新启动通常比“冷启动”快得多,因为base类加载器已经可用并已填充。当我们开启devtools后,classpath中的文件变化会导致应用自动重启
(ps:Eclipse中保存文件即可引起classpath更新(注:需要打开自动编译),从而触发重启。而IDEA则需要自己手动CTRL+F9重新编译一下)