钉钉的部门群有个钉钉机器人本来是每天进行业务数据统计并进行推送的,发现某天到了指定的cron时间点,但没有推送,然后去探索了下schedule相关的代码。
主要是这个方法
org.springframework.scheduling.config.ScheduledTaskRegistrar#scheduleTasks
其中如果taskScheduler 为空,会使用单线程的定时任务执行器
protected void scheduleTasks() {
if (this.taskScheduler == null) {
// 这里是 使用一个单线程的 ScheduledExecutor
this.localExecutor = Executors.newSingleThreadScheduledExecutor();
this.taskScheduler = new ConcurrentTaskScheduler(this.localExecutor);
}
if (this.triggerTasks != null) {
for (TriggerTask task : this.triggerTasks) {
addScheduledTask(scheduleTriggerTask(task));
}
}
if (this.cronTasks != null) {
for (CronTask task : this.cronTasks) {
addScheduledTask(scheduleCronTask(task));
}
}
if (this.fixedRateTasks != null) {
for (IntervalTask task : this.fixedRateTasks) {
addScheduledTask(scheduleFixedRateTask(task));
}
}
if (this.fixedDelayTasks != null) {
for (IntervalTask task : this.fixedDelayTasks) {
addScheduledTask(scheduleFixedDelayTask(task));
}
}
}
问这段代码时候被调用?
在使用定时任务时我们使用了注解@EnableScheduling, 这个注解可以看到,它会@Import 一个 SchedulingConfiguration 配置类
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(SchedulingConfiguration.class)
@Documented
public @interface EnableScheduling {
}
SchedulingConfiguration 配置类,会加载一个ScheduledAnnotationBeanPostProcessor 的对象。
@Configuration
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class SchedulingConfiguration {
@Bean(name = TaskManagementConfigUtils.SCHEDULED_ANNOTATION_PROCESSOR_BEAN_NAME)
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public ScheduledAnnotationBeanPostProcessor scheduledAnnotationProcessor() {
return new ScheduledAnnotationBeanPostProcessor();
}
}
它的构造方法中会创建一个ScheduledTaskRegistrar ,同时它是实现了InitializingBean 接口的类
public ScheduledAnnotationBeanPostProcessor() {
this.registrar = new ScheduledTaskRegistrar();
}
类初始化的时候会调用到afterPropertiesSet 方法,进而调用到了scheduleTasks
@Override
public void afterPropertiesSet() {
// 定时任务的注册
scheduleTasks();
}
网上查找方法一般会找到两种
这里提供一个网上的参考方案
spring scheduled单线程和多线程使用过程中的大坑!!不看到时候绝对后悔!!_FlyingSnails的博客-CSDN博客_scheduled 单线程
方案中提到的使用自己的配置SchedulingConfigurer 的方式有一定的弊端,说如果同一个Schedule 任务,执行使用的线程是同一个线程,前一个任务执行超过任务间隔,会影响后一个任务的执行。
当然如果场景是不同的schedule任务,并且每个任务执行时间小于指定间隔时间的话其实是是可以使用这种方式进行配置处理的。
问这个配置在什么时候会被加载
因为 ScheduledAnnotationBeanPostProcessor 实现了 ApplicationListener ,所以在 spring 容器 refresh() 的时候调用到
@Override
public void onApplicationEvent(ContextRefreshedEvent event) {
if (event.getApplicationContext() == this.applicationContext) {
// Running in an ApplicationContext -> register tasks this late...
// giving other ContextRefreshedEvent listeners a chance to perform
// their work at the same time (e.g. Spring Batch's job registration).
finishRegistration();
}
}
private void finishRegistration() {
if (this.scheduler != null) {
this.registrar.setScheduler(this.scheduler);
}
if (this.beanFactory instanceof ListableBeanFactory) {
Map beans =
// 从 ioc 容器中获取 类型为 SchedulingConfigurer 的bean
((ListableBeanFactory) this.beanFactory).getBeansOfType(SchedulingConfigurer.class);
List configurers = new ArrayList<>(beans.values());
AnnotationAwareOrderComparator.sort(configurers);
for (SchedulingConfigurer configurer : configurers) {
configurer.configureTasks(this.registrar);
}
}
}
可以看到上面代码中 beanFactory.getBeansOfType(SchedulingConfigurer.class) 获取配置的实现了 SchedulingConfigurer 类型的bean对象
所以这里要注意:实现 SchedulingConfigurer 接口的类必须要被实例化一个 Bean 对象,否则无法找到对应的配置信息。
题外话:继续看 finishRegistration 方法,会发现如果我们配置了任务但 registrar.getScheduler() 为空的时候,spring会先尝试找 TaskScheduler 类型的bean
对应的代码如下
if (this.registrar.hasTasks() && this.registrar.getScheduler() == null) {
Assert.state(this.beanFactory != null, "BeanFactory must be set to find scheduler by type");
try {
// Search for TaskScheduler bean...
// 走类型查找 TaskScheduler
this.registrar.setTaskScheduler(resolveSchedulerBean(this.beanFactory, TaskScheduler.class, false));
}
catch (NoUniqueBeanDefinitionException ex) {
// 没有唯一的bean
if (logger.isTraceEnabled()) {
logger.trace("Could not find unique TaskScheduler bean - attempting to resolve by name: " +
ex.getMessage());
}
try {
// 根据类名找
this.registrar.setTaskScheduler(resolveSchedulerBean(this.beanFactory, TaskScheduler.class, true));
}
catch (NoSuchBeanDefinitionException ex2) {
if (logger.isInfoEnabled()) {
logger.info("More than one TaskScheduler bean exists within the context, and " +
"none is named 'taskScheduler'. Mark one of them as primary or name it 'taskScheduler' " +
"(possibly as an alias); or implement the SchedulingConfigurer interface and call " +
"ScheduledTaskRegistrar#setScheduler explicitly within the configureTasks() callback: " +
ex.getBeanNamesFound());
}
}
}
catch (NoSuchBeanDefinitionException ex) {
if (logger.isTraceEnabled()) {
logger.trace("Could not find default TaskScheduler bean - attempting to find ScheduledExecutorService: " +
ex.getMessage());
}
// Search for ScheduledExecutorService bean next...
try {
// 走类型查找 ScheduledExecutorService
this.registrar.setScheduler(resolveSchedulerBean(this.beanFactory, ScheduledExecutorService.class, false));
}
catch (NoUniqueBeanDefinitionException ex2) {
// 多个 bean
if (logger.isTraceEnabled()) {
logger.trace("Could not find unique ScheduledExecutorService bean - attempting to resolve by name: " +
ex2.getMessage());
}
try {
// 根据类名找
this.registrar.setScheduler(resolveSchedulerBean(this.beanFactory, ScheduledExecutorService.class, true));
}
catch (NoSuchBeanDefinitionException ex3) {
if (logger.isInfoEnabled()) {
logger.info("More than one ScheduledExecutorService bean exists within the context, and " +
"none is named 'taskScheduler'. Mark one of them as primary or name it 'taskScheduler' " +
"(possibly as an alias); or implement the SchedulingConfigurer interface and call " +
"ScheduledTaskRegistrar#setScheduler explicitly within the configureTasks() callback: " +
ex2.getBeanNamesFound());
}
}
}
catch (NoSuchBeanDefinitionException ex2) {
if (logger.isTraceEnabled()) {
logger.trace("Could not find default ScheduledExecutorService bean - falling back to default: " +
ex2.getMessage());
}
// Giving up -> falling back to default scheduler within the registrar...
logger.info("No TaskScheduler/ScheduledExecutorService bean found for scheduled processing");
}
}
}
由此可见,如果是自己配置一个 TaskScheduler,类型的bean对象其实也能实现线程池的方式,不一定需要一个bean 实现SchedulingConfigurer 接口。
所以有结论,配置bean 的方式实现多线程其实有 两种方式:
一、配置实现SchedulingConfigurer 的bean
二、配置实现TaskScheduler 的bean
问为什么任务超过时间间隔后会影响后一个任务
请特别留意一下 org.springframework.scheduling.concurrent.ReschedulingRunnable 类的 run 方法和schedule 方法。
当org.springframework.scheduling.config.ScheduledTaskRegistrar#scheduleTasks 被调用的时候,会进行task 的注册,然后调用到org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler#schedule 方法,它会返回ScheduledFuture ,他其实是 new 了一个 ReschedulingRunnable 并且调用了schedule。
new ReschedulingRunnable(task, trigger, executor, errorHandler).schedule();
@Nullable
public ScheduledFuture> schedule() {
synchronized (this.triggerContextMonitor) {
this.scheduledExecutionTime = this.trigger.nextExecutionTime(this.triggerContext);
if (this.scheduledExecutionTime == null) {
return null;
}
long initialDelay = this.scheduledExecutionTime.getTime() - System.currentTimeMillis();
this.currentFuture = this.executor.schedule(this, initialDelay, TimeUnit.MILLISECONDS);
return this;
}
}
@Override
public void run() {
Date actualExecutionTime = new Date();
super.run();
Date completionTime = new Date();
synchronized (this.triggerContextMonitor) {
Assert.state(this.scheduledExecutionTime != null, "No scheduled execution");
this.triggerContext.update(this.scheduledExecutionTime, actualExecutionTime, completionTime);
if (!obtainCurrentFuture().isCancelled()) {
schedule();
}
}
}
这段方法巧妙的地方在于第9行和第23行的搭配调用。
第一次注册任务时触发schedule 方法(重点!!入参的第一个对象是当前线程)等到间隔时间后执行run 方法,super.run() 其实执行的就是我们定义好的任务代码,执行完后判断obtainCurrentFuture().isCancelled() 是否取消执行,没有的话再次调用schedule 方法。
这样的方法相当于线程套线程,只要任务不结束线程就不会停止,一开始我还在找触发的地方,一直没找到看到schedule 中的第一个入参是个this ,然后就释然了。
从这段方法可以发现,如果我们的任务没有执行完,是不会触发下一次schedule 的调用的,所以之前总担心cron 配置的任务间隔过短的话会启动多个任务,现在看来其实是多虑了。。。
使用@Async 实现其实是借助了spring aop 对执行的方法进行增强,每次执行时都是最终调用了MethodInterceptor 的invoke 方法,对目标方法进行增强
使用注解EnableAsync 时,会加载AsyncConfigurationSelector 类,它会通过selectImports 方法,告诉spring加载ProxyAsyncConfiguration。
这个地方其实是两种模式的,在配置EnableAsync 的时候可以设置mode 属性,然后根据mode 选择不同的配置类,这里默认是PROXY,所以只关注ProxyAsyncConfiguration 类即可。
public class AsyncConfigurationSelector extends AdviceModeImportSelector {
private static final String ASYNC_EXECUTION_ASPECT_CONFIGURATION_CLASS_NAME =
"org.springframework.scheduling.aspectj.AspectJAsyncConfiguration";
/**
* Returns {@link ProxyAsyncConfiguration} or {@code AspectJAsyncConfiguration}
* for {@code PROXY} and {@code ASPECTJ} values of {@link EnableAsync#mode()},
* respectively.
*/
@Override
@Nullable
public String[] selectImports(AdviceMode adviceMode) {
switch (adviceMode) {
case PROXY:
return new String[] {ProxyAsyncConfiguration.class.getName()};
case ASPECTJ:
return new String[] {ASYNC_EXECUTION_ASPECT_CONFIGURATION_CLASS_NAME};
default:
return null;
}
}
}
ProxyAsyncConfiguration 中会向容器注入AsyncAnnotationBeanPostProcessor bean,这个bean实现了两个接口
第一个 BeanFactoryAware.setBeanFactory() 的时候 new AsyncAnnotationAdvisor ,在这个Advisor 中主要做了两件事情
第二个 BeanPostProcessor.postProcessAfterInitialization 方法,其实是调用了父类AbstractAdvisingBeanPostProcessor
的postProcessAfterInitialization() 这个方法中关键的一个地方是通过ProxyFactory 来生成对应增强代理类。
public Object postProcessAfterInitialization(Object bean, String beanName) {
// ... 其他代码
if (isEligible(bean, beanName)) {
ProxyFactory proxyFactory = prepareProxyFactory(bean, beanName);
if (!proxyFactory.isProxyTargetClass()) {
evaluateProxyInterfaces(bean.getClass(), proxyFactory);
}
proxyFactory.addAdvisor(this.advisor);
customizeProxyFactory(proxyFactory);
return proxyFactory.getProxy(getProxyClassLoader());
}
// No proxy needed.
return bean;
}
其中isEligible 方法,最终是调用AopUtils 类的方法来判定,当前bean 对象是否能被Advisor 增强。
AopUtils.canApply(this.advisor, targetClass);
问如何生成代理类?
面试常问spring如何生成代理对象,其实答案就在ProxyFactory 里面。
当使用ProxyFactory.getProxy() 的时候,会先获取AopProxy 对象,而获取AopProxy 对象时,你就能发现,最终返回的只有两种Proxy,一个是JdkDynamicAopProxy ,一个是ObjenesisCglibAopProxy。
ProxyFactory.class
public Object getProxy(@Nullable ClassLoader classLoader) {
return createAopProxy().getProxy(classLoader);
}
------
ProxyCreatorSupport.class
protected final synchronized AopProxy createAopProxy() {
if (!this.active) {
activate();
}
return getAopProxyFactory().createAopProxy(this);
}
------
DefaultAopProxyFactory.class:
public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
Class> targetClass = config.getTargetClass();
if (targetClass == null) {
throw new AopConfigException("TargetSource cannot determine target class: " +
"Either an interface or a target is required for proxy creation.");
}
if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) {
return new JdkDynamicAopProxy(config);
}
return new ObjenesisCglibAopProxy(config);
}
else {
return new JdkDynamicAopProxy(config);
}
}
定时任务的执行主要是由ScheduledAnnotationBeanPostProcessor.postProcessAfterInitialization() 方法进行触发。
方法中会扫描所有@Scheduled 注释的方法,然后对这些方法执行processScheduled
protected void processScheduled(Scheduled scheduled, Method method, Object bean) {
try {
Runnable runnable = createRunnable(bean, method);
boolean processedSchedule = false;
String errorMessage =
"Exactly one of the 'cron', 'fixedDelay(String)', or 'fixedRate(String)' attributes is required";
Set tasks = new LinkedHashSet<>(4);
// 其他 任务类型处理
// Check cron expression
String cron = scheduled.cron();
if (StringUtils.hasText(cron)) {
String zone = scheduled.zone();
if (this.embeddedValueResolver != null) {
cron = this.embeddedValueResolver.resolveStringValue(cron);
zone = this.embeddedValueResolver.resolveStringValue(zone);
}
if (StringUtils.hasLength(cron)) {
Assert.isTrue(initialDelay == -1, "'initialDelay' not supported for cron triggers");
processedSchedule = true;
if (!Scheduled.CRON_DISABLED.equals(cron)) {
TimeZone timeZone;
if (StringUtils.hasText(zone)) {
timeZone = StringUtils.parseTimeZoneString(zone);
}
else {
timeZone = TimeZone.getDefault();
}
tasks.add(this.registrar.scheduleCronTask(new CronTask(runnable, new CronTrigger(cron, timeZone))));
}
}
}
// 其他 任务类型处理
// Check whether we had any attribute set
Assert.isTrue(processedSchedule, errorMessage);
// Finally register the scheduled tasks
synchronized (this.scheduledTasks) {
Set regTasks = this.scheduledTasks.computeIfAbsent(bean, key -> new LinkedHashSet<>(4));
regTasks.addAll(tasks);
}
}
catch (IllegalArgumentException ex) {
throw new IllegalStateException(
"Encountered invalid @Scheduled method '" + method.getName() + "': " + ex.getMessage());
}
}
其中重点方法是createRunnable ,它会生成ScheduledMethodRunnable 对象
protected Runnable createRunnable(Object target, Method method) {
Assert.isTrue(method.getParameterCount() == 0, "Only no-arg methods may be annotated with @Scheduled");
Method invocableMethod = AopUtils.selectInvocableMethod(method, target.getClass());
return new ScheduledMethodRunnable(target, invocableMethod);
}
从上面第一部分解析可以指导任务都是由ReschedulingRunnable 线程自己调用自己实现定时执行,那它最终run 的方法其实是ScheduledMethodRunnable 的run 方法。
public void run() {
try {
ReflectionUtils.makeAccessible(this.method);
this.method.invoke(this.target);
}
catch (InvocationTargetException ex) {
ReflectionUtils.rethrowRuntimeException(ex.getTargetException());
}
catch (IllegalAccessException ex) {
throw new UndeclaredThrowableException(ex);
}
}
这里如果是第一种方案的话,this.target 是普通的代理对象,调用方法是同步执行的,第一个任务执行完才会触发第二个任务执行。
如果是第二种方案的话,this.target 是带有增强逻辑的代理对象
真正执行的方法是org.springframework.aop.framework.CglibAopProxy.DynamicAdvisedInterceptor#intercept 方法
然后是org.springframework.aop.framework.CglibAopProxy.CglibMethodInvocation#proceed 方法
再然后是org.springframework.aop.framework.ReflectiveMethodInvocation#proceed,最终执行的是else 结构,也就是((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
public Object proceed() throws Throwable {
// We start with an index of -1 and increment early.
if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
return invokeJoinpoint();
}
Object interceptorOrInterceptionAdvice =
this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {
// Evaluate dynamic method matcher here: static part will already have
// been evaluated and found to match.
InterceptorAndDynamicMethodMatcher dm =
(InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
Class> targetClass = (this.targetClass != null ? this.targetClass : this.method.getDeclaringClass());
if (dm.methodMatcher.matches(this.method, targetClass, this.arguments)) {
return dm.interceptor.invoke(this);
}
else {
// Dynamic matching failed.
// Skip this interceptor and invoke the next in the chain.
return proceed();
}
}
else {
// It's an interceptor, so we just invoke it: The pointcut will have
// been evaluated statically before this object was constructed.
return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
}
}
这里的interceptorOrInterceptionAdvice 其实就是AnnotationAsyncExecutionInterceptor,在invoke 方法中会获取配置taskScheduler ,进行任务处理,而这里就是把任务一个个丢到线程池里执行,这个就是和第一种方式最大的区别。
public Object invoke(final MethodInvocation invocation) throws Throwable {
Class> targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);
Method specificMethod = ClassUtils.getMostSpecificMethod(invocation.getMethod(), targetClass);
final Method userDeclaredMethod = BridgeMethodResolver.findBridgedMethod(specificMethod);
AsyncTaskExecutor executor = determineAsyncExecutor(userDeclaredMethod);
if (executor == null) {
throw new IllegalStateException(
"No executor specified and no default executor set on AsyncExecutionInterceptor either");
}
Callable
到这里其实你会发现,第一种配置方式和第二种配置方式道理上都是相同的,都是ReschedulingRunnable 的run 和schedule 配合触发定时执行任务,不同的地方在于执行任务时处理任务的方式不同(一个是单线程调用,一个是多线程调用)
再仔细想想,第一种配置是将不同的任务放在不同的线程中执行,任务数超过线程池线程数,就会有等待的情况;第二种是不同的任务在单线程处理所有的定时任务,每次处理的任务都是丢给另外一个线程池进行执行 enmmmm 是这样的
本文涉及涉及知识点:
@Import 的使用
实现InitializingBean 接口类的初始化
实现BeanFactoryAware 接口类的初始化
实现ApplicationListener 接口类的初始化
bean 的初始化过程
BeanPostProcessor 接口类
spring 生成代理对象
spring 实现aop(Advisor Advice Pointcut)
未解决的问题
大家可以继续探索: