问题描述:

java.lang.ClassCastException: com.example.demo.domain.User cannot be cast to com.example.demo.domain.User

解决方案：

Goole大法

When you use DevTools with caching, you need to be aware of this limitation.
When the object is serialized into the cache, the application class loader is C1. Then after you change some code/configuration, devtools automatically restart the context and creates a new classloader (C2). When you hit that cache method, the cache abstraction finds an entry in the cache and it deserializes it from the store. If the cache library doesn’t take the context classloader into account, that object will have the wrong classloader attached to it (which explains that weird exception A cannot be cast to A).

上面这段话是Stack Overflow社区一大佬就此问题的回答，大意是说，当使用SpringBoot 的 DevTools时，其实该工具是具有缓存效果的，这点需要注意，而且该大佬也提供的注意事项的连接地址 this limitation.

当对象被序列化到缓存里时，当前应用的类加载器是C1，当你改变了一些代码或者配置文件的时候，DevTools 工具将会自动重新启动这个容器，并且创建一个新的类加载器 C2. 这时候调用这个具有缓存的方法时，缓存管理将会从缓存里找到该条缓存记录并进行反序列化操作。如果缓存库不考虑上下文的话，也就是没注意到类加载器的变化时，该对象将会有错误的类加载器(这解释了奇怪的异常)。

其实就是因上下文类加载器不同而产生这样的错误，那么归根结底就是因SpringBoot DevTools工具搞的鬼。

将下面的热部署的依赖注释，重启服务器就好了。

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

参考:https://chenzhihao.cc/archives/526