|
问题 在我们的项目中，有这样两个类（示意）： @Componentpublic class FatherScheduler { @Scheduled(cron = "0/10 * * * * ?") public void execute() { System.out.println(new Date() + " 执行任务的类是：" + this.getClass()); }}
@Componentpublic class SonSchedulerImpl extends FatherScheduler { @Override @Scheduled(cron = "1/10 * * * * ?") public void execute() { super.execute(); }}
这是一对父子类。FatherScheduler定义了一个定时任务，并利用Spring-Scheduler注解声明了每10秒调度执行一次。SonSchedulerImpl继承了FatherScheduler，重写了该定时任务的注解。 线上系统中，我们已有一个逻辑比较完备的定时任务父类；子类只需要修改父类的一个注入实例、修改cron表达式即可。所以出现了这样的类结构。 我们希望父类定义的定时任务在启动后的第0/10/20/30……秒启动执行；子类定时任务则在第1/11/21/31……秒启动执行。从代码上看似乎没有问题，但是实际执行结果是这样的： Tue Jul 30 10:54:40 CST 2019 执行任务的类是：class net.loyintean.blog.scheduer.FatherSchedulerTue Jul 30 10:54:40 CST 2019 执行任务的类是：class net.loyintean.blog.scheduer.SonSchedulerImplTue Jul 30 10:54:41 CST 2019 执行任务的类是：class net.loyintean.blog.scheduer.SonSchedulerImplTue Jul 30 10:54:50 CST 2019 执行任务的类是：class net.loyintean.blog.scheduer.FatherSchedulerTue Jul 30 10:54:50 CST 2019 执行任务的类是：class net.loyintean.blog.scheduer.SonSchedulerImplTue Jul 30 10:54:51 CST 2019 执行任务的类是：class net.loyintean.blog.scheduer.SonSchedulerImpl
也就是说，父类定时任务确实是按照我们的期望在调度执行。但是子类定时任务……在我们的预期之外，它多做了一次调度，而且调度规律与父类相同（红色字体部分）。虽然我们对定时任务都做了幂等处理，即使多跑了几次也只是浪费点服务器性能而已，但是代码应该做且只做我们要做的事，不应该做多余的事——否则说不定哪天“天网”系统就要诞生了哈哈。 原因 从代码运行表现来看，似乎是Spring-Scheduler在为子类注册定时任务时，除了解析子类重写方法上的@Scheduled注解之外，还把父类方法上的注解也解析了一遍。但是到底是不是这样，还是要去找注册定时任务的相关代码。 找到@Scheduled注解，可以看到它在的javadoc中已经指明了这个注解是在哪儿处理的了： Processing of {@code @Scheduled} annotations is performed by registering a {@link ScheduledAnnotationBeanPostProcessor}. This can be done manually or, more conveniently, through the {@code <task:annotation-driven/>} element or @{@link EnableScheduling} annotation. 这也算一个启示：好好写Javadoc。一份好的Javadoc能为使用代码、维护代码的人提供很大的便利。 ScheduledAnnotationBeanPostProcessor的定义和核心处理代码是这样的： public class ScheduledAnnotationBeanPostProcessor implements BeanPostProcessor, Ordered, EmbeddedValueResolverAware, BeanFactoryAware, ApplicationContextAware, SmartInitializingSingleton, ApplicationListener<ContextRefreshedEvent>, DisposableBean { @Override public Object postProcessAfterInitialization(final Object bean, String beanName) { Class<?> targetClass = AopUtils.getTargetClass(bean); if (!this.nonAnnotatedClasses.contains(targetClass)) { final Set<Method> annotatedMethods = new LinkedHashSet<Method>(1); ReflectionUtils.doWithMethods(targetClass, new MethodCallback() { @Override public void doWith(Method method) throws IllegalArgumentException, IllegalAccessException { for (Scheduled scheduled : AnnotationUtils.getRepeatableAnnotation(method, Schedules.class, Scheduled.class)) { processScheduled(scheduled, method, bean); annotatedMethods.add(method); } } }); if (annotatedMethods.isEmpty()) { this.nonAnnotatedClasses.add(targetClass); if (logger.isDebugEnabled()) { logger.debug("No @Scheduled annotations found on bean class: " + bean.getClass()); } } else { // Non-empty set of methods if (logger.isDebugEnabled()) { logger.debug(annotatedMethods.size() + " @Scheduled methods processed on bean '" + beanName + "': " + annotatedMethods); } } } return bean; } }
简单看下来，其中的核心逻辑在ReflectionUtils.doWithMethods方法中。这个方法内部是这样的： public static void doWithMethods(Class<?> clazz, ReflectionUtils.MethodCallback mc, ReflectionUtils.MethodFilter mf) { Method[] methods = getDeclaredMethods(clazz); Method[] var4 = methods; int var5 = methods.length;
int var6; for(var6 = 0; var6 < var5; ++var6) { Method method = var4[var6]; if (mf == null || mf.matches(method)) { try { mc.doWith(method); } catch (IllegalAccessException var9) { throw new IllegalStateException("Not allowed to access method '" + method.getName() + "': " + var9); } } }
if (clazz.getSuperclass() != null) { doWithMethods(clazz.getSuperclass(), mc, mf); } else if (clazz.isInterface()) { Class[] var10 = clazz.getInterfaces(); var5 = var10.length;
for(var6 = 0; var6 < var5; ++var6) { Class<?> superIfc = var10[var6]; doWithMethods(superIfc, mc, mf); } }
}
哎~果不其然地，我们在这个类里面发现了递归调用父类的代码： if (clazz.getSuperclass() != null) { doWithMethods(clazz.getSuperclass(), mc, mf); }结合mc.doWith()方法的定义：new MethodCallback() { @Override public void doWith(Method method) throws IllegalArgumentException, IllegalAccessException { for (Scheduled scheduled : AnnotationUtils.getRepeatableAnnotation(method, Schedules.class, Scheduled.class)) { processScheduled(scheduled, method, bean); annotatedMethods.add(method); } }}
问题原因就很明显了： ScheduledAnnotationBeanPostProcessor在处理SonSchedulerImpl实例的时候，首先找出了子类重写过的execute()方法及其Scheduled注解，并为其注册了一个定时任务。随后，又按同样的逻辑，找到的它的父类FatherScheduler上定义的execute()方法及其Scheduled注解，又按父类的配置注册了一个定时任务。这样，同一个bean实例上就注册了两个定时任务，从而导致同一个定时任务被调度了两次。 解决方案 解决方案有两个。 首先就是……父类方法上不要注解@Scheduled。为了能尽量复用代码、又能不在父类上注解@Scheduled，我们最后把代码改成了这样： public class FatherScheduler { public void execute() { System.out.println(new Date() + " 执行任务的类是：" + this.getClass()); }}
@Componentpublic class SonSchedulerImpl extends FatherScheduler { @Override @Scheduled(cron = "1/10 * * * * ?") public void execute() { super.execute(); }}
@Componentpublic class DaughterSchedulerImpl { @Scheduled(cron = "0/10 * * * * ?") public void execute() { super.execute(); }}
也就是父类只定义业务逻辑，不做@Scheduled注解。两个子类分别注解。 另一种方式更彻底一些：升级Spring版本。这个问题目前已知是在4.1.6.RELEASE版本中出现的；在最新版的5.1.8RELEASE中已经被修复了。这个版本中调用ReflectionUtils.doWithMethods时，传入的是这样的一个回调方法： ReflectionUtils.doWithMethods(currentHandlerType, method -> { Method specificMethod = ClassUtils.getMostSpecificMethod(method, targetClass); T result = metadataLookup.inspect(specificMethod); if (result != null) { Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(specificMethod); if (bridgedMethod == specificMethod || metadataLookup.inspect(bridgedMethod) == null) { methodMap.put(specificMethod, result); } } }, ReflectionUtils.USER_DECLARED_METHODS);}
注意其中的这一行代码： Method specificMethod = ClassUtils.getMostSpecificMethod(method, targetClass);
这行代码的作用在于，从targetClass上找出它重写过的method方法。在出现问题的流程中，targetClass始终指向子类SonSchedulerImpl；而method则会随着ReflectionUtils.doWithMethods的递归调用而从SonSchedulerImpl#execute()方法变成了FatherScheduler#execute()方法。但是，经过ClassUtils.getMostSpecificMethod()方法的处理后，我们最终得到的specificMethod仍是子类重写的SonSchedulerImpl#execute()方法，而非父类上原生的FatherScheduler#execute()方法。这样一来，后续处理中也就只会按照子类方法上的@Scheduled注解来注册定时任务了。 这是第二个启示：框架工具应及时升级，以避免踩中别人已经填上的坑。
|
