Quartz在spring-boot中使用了spring-boot-devtools带来的问题
由于项目中会使用到定时任务，选型时选用了Quartz来进行任务管理和控制，之前配置定时任务后启动、暂停等操作都能正常，但是最近为了前端调试方便，添加了热部署的配置依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>
</dependency>
然后就引发了一个奇怪的问题。详见下文：
org.quartz.SchedulerException: Job threw an unhandled exception.
java.lang.ClassCastException: com.ac.modules.job.entity.ScheduleJobEntity cannot be cast to com.ac.modules.job.entity.ScheduleJobEntity
at com.ac.modules.job.utils.ScheduleJob.executeInternal(ScheduleJob.java:33)
at org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:75)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)
2021-08-12 23:56:55.086 ERROR 20864 --- [eduler_Worker-1] org.quartz.core.ErrorLogger : Job (DEFAULT.TASK_1234111111111111111 threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception.
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)
Caused by: java.lang.ClassCastException: com.ac.modules.job.entity.ScheduleJobEntity cannot be cast to com.ac.modules.job.entity.ScheduleJobEntity
at com.ac.modules.job.utils.ScheduleJob.executeInternal(ScheduleJob.java:33)
at org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:75)
at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
... 1 common frames omitted
WTF？！同一个包中，同一个类型还出现了类型转换异常？！各种添加断点调试，每当执行到从JobDataMap中取出任务对象时，100%出现该异常：
JobDataMap jobDataMap = context.getMergedJobDataMap();
Object taskObj = jobDataMap.get(ScheduleJobEntity.JOB_PARAM_KEY);
ScheduleJobEntity scheduleJob = (ScheduleJobEntity) taskObj;
解决思路
这么奇怪的现象，老夫多年是从未见过啊，花了半个小时，事实证明是在浪费时间，于是就回滚到能正常启动处提交，结果一切OK，这是要气死我的节奏…
仔细一想，不对，难道是杠添加的什么配置引起的，上面JobDataMap中取任务对象，还能有别的写法，不做类型转换？这不可能。于是一个一个修改过的文件检查，发现了罪魁祸首：spring-boot-devtools
于是，把它干掉，一切又OK了。
深入思考
说到热部署，那少不了让JVM判断两个类对象是否相同，其的依据一是类全称；一个是类加载器，既然不是类名的问题，那肯定就是类加载器不同导致的。
果然，spring-boot-devtools会检测类路径的变化，当类路径内容发生变化后会自动重启应用程序。Spring Boot的重启技术通过使用两个类加载器。由于使用的是双类加载机制重启会非常快，如果启动较慢也可使用JRebel重加载技术。
（1）base classloader （Base类加载器）：加载不改变的Class，如第三方提供的jar包。
（2）restart classloader（Restart类加载器）：加载正在开发的Class。
其他解决办法参考
stackoverflow：
This is a known limitation of Devtools. When the cache entry is deserialized, the object is not attached to the proper classloader.
There are various ways you can fix this issue:
1，Disable cache when you’re running your application in development
2，Use a different cache manager (if you’re using Spring Boot 1.3, you could force a simple cache manager using the spring.cache.type property in application-dev.properties and enable the dev profile in your IDE)
3，Configure memcached (and things that are cached) to run in the application classloader. I wouldn’t recommend that option since the two first above are much easier to implement
译文：
这是Devtools的已知限制，当反序列化高速缓存条目时，该对象未附加到类加载器。你可以通过多种方式解决此问题：
1，在开发中运行应用程序时禁用缓存。
2，使用其他缓存管理器（如果您使用的是Spring Boot 1.3，则可以使用application-dev.properties中的spring.cache.type属性强制使用简单的缓存管理器，并在IDE中启用开发配置文件）。
3，配置memcached（以及缓存的内容）以在应用程序类加载器中运行。我不建议使用该选项，因为上面的前两个更容易实现。
|