同类型转换抛出ClassCastException：类加载器问题排查

我之前也碰到过一模一样的问题！这确实是Spring DevTools的类加载机制带来的典型坑，下面给你几个可行的解决方案，既能保住热部署功能，又能彻底解决类转换异常：

核心原因 #

Spring DevTools为了实现快速热重启，用了RestartClassLoader来加载你的应用代码，而系统主类加载器负责加载第三方依赖和核心类。当你的Usuario实体被RestartClassLoader加载后，Hibernate从Session返回的实例是这个类加载器的对象，但业务代码里引用的Usuario.class是主类加载器加载的版本——JVM会把来自不同类加载器的同名类当成完全不同的类型，这就出现了看起来诡异的application.model.Usuario cannot be cast to application.model.Usuario异常。

解决方案 #

1. 配置DevTools排除实体类包 #

在application.properties（或application.yml）里添加配置，让实体类包由主类加载器加载，避开RestartClassLoader：

# 排除实体类所在包，防止被RestartClassLoader重复加载
spring.devtools.restart.exclude=application/model/**

如果实体类分散在多个包，用逗号分隔即可：

spring.devtools.restart.exclude=application/model/**,application/entity/**

2. 更精细的加载控制（可选） #

如果想保留部分包的热重启能力，同时排除实体类，可以用additional-exclude追加排除规则：

# 保留默认排除规则，额外添加实体类包的排除
spring.devtools.restart.additional-exclude=application/model/**

或者反过来，指定只有特定包参与热重启，实体类包不参与：

# 仅让业务逻辑、安全模块参与热重启，实体类包交给主加载器
spring.devtools.restart.include=application/core/**,application/security/**

3. 将实体类抽为独立模块（进阶方案） #

如果项目结构允许，把实体类单独做成一个Maven模块（比如your-project-model），然后在主应用模块中依赖这个模块。DevTools默认不会对第三方依赖（包括你自己的模块）使用RestartClassLoader，这样实体类会由主类加载器统一加载，从根源避免类加载冲突。

验证方法 #

配置完成后重启Spring Boot应用，调用findById方法测试，ClassCastException应该会消失，同时修改业务代码时，DevTools依然会自动重启应用，热部署的便利也能保留。

内容的提问来源于stack exchange，提问作者Alain Cruz