问题
在我们的项目中,有这样两个类(示意):
@Component
public class FatherScheduler {
@Scheduled(cron = "0/10 * * * * ?")
public void execute() {
System.out.println(new Date() + " 执行任务的类是:" + this.getClass());
}
}
@Component
public 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.FatherScheduler
Tue Jul 30 10:54:40 CST 2019 执行任务的类是:class net.loyintean.blog.scheduer.SonSchedulerImpl Tue Jul 30 10:54:41 CST 2019 执行任务的类是:class net.loyintean.blog.scheduer.SonSchedulerImpl
Tue Jul 30 10:54:50 CST 2019 执行任务的类是:class net.loyintean.blog.scheduer.FatherScheduler
Tue Jul 30 10:54:50 CST 2019 执行任务的类是:class net.loyintean.blog.scheduer.SonSchedulerImpl > Tue 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.
Scheduled注解的javadoc(节选)
这也算一个启示:好好写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());
}
}
@Component
public class SonSchedulerImpl extends FatherScheduler {
@Override
@Scheduled(cron = "1/10 * * * * ?")
public void execute() {
super.execute();
}
}
@Component
public 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注解来注册定时任务了。
这是第二个启示:框架工具应及时升级,以避免踩中别人已经填上的坑。