Timed out while waiting for executor ‘taskScheduler‘ to terminate

在使用Spring @Scheduled注解时,配置线程池后,程序关闭时遇到超时问题。文章探讨了ScheduledThreadPoolExecutor等待任务结束的原因,并提供了修改ThreadPoolTaskScheduler以避免超时的方法,包括设置executeExistingDelayedTasksAfterShutdownPolicy为false。

使用@Scheduled 注解,我们一般会为其配置上一个线程池,我在写一个简单demo的时候,发现配上线程池后,关闭程序时,会打印出如下日志,

2021-07-12 23:50:10.381 [tid: ][skId: ] [SpringContextShutdownHook] INFO o.s.s.c.ThreadPoolTaskScheduler:218 - Shutting down ExecutorService ‘taskScheduler’
2021-07-12 23:50:12.387 [tid: ][skId: ] [SpringContextShutdownHook] WARN o.s.s.c.ThreadPoolTaskScheduler:256 - Timed out while waiting for executor ‘taskScheduler’ to terminate
2021-07-12 23:50:12.387 [tid: ][skId: ] [SpringContextShutdownHook] INFO o.s.s.c.ThreadPoolTaskScheduler:218 - Shutting down ExecutorService ‘taskScheduler’
2021-07-12 23:50:14.391 [tid: ][skId: ] [SpringContextShutdownHook] WARN o.s.s.c.ThreadPoolTaskScheduler:256 - Timed out while waiting for executor ‘taskScheduler’ to terminate
2021-07-12 23:50:14.405 [tid: ][skId: ] [SpringContextShutdownHook] INFO c.z.hikari.HikariDataSource:350 - village_test-POOL - Shutdown initiated…
2021-07-12 23:50:14.419 [tid: ][skId: ] [SpringContextShutdownHook] INFO c.z.hikari.HikariDataSource:352 - village_test-POOL - Shutdown completed.

我的线程池配置如下

	@Bean(destroyMethod = "shutdown")
    public ThreadPoolTaskScheduler taskScheduler() {
        ThreadPoolTaskScheduler executor = new ThreadPoolTaskScheduler();
        executor.setPoolSize(2);
        executor.setThreadNamePrefix("selfSchedule@");
        executor.setAwaitTerminationSeconds(2);
        executor.setWaitForTasksToCompleteOnShutdown(true);
        return executor;
    }

我要执行的任务,其实只是一个很简单的遍历任务,循环一次耗时远小于1s,我给的等待时间有2s,为什么还是会报超时问题呢?

查询了下Stack Overflow ,记录下原因。

Because by default the ScheduledThreadPoolExecutor will wait for all delayed scheduled tasks to finish executing, even if scheduled tasks aren’t running at that time.

即使任务并不在执行中,ScheduledThreadPoolExecutor还是会等待任务结束执行。

解决方式如下:

@Bean
public TaskScheduler taskScheduler() {
    ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler() {
        private static final long serialVersionUID = -1L;
        @Override
        public void destroy() {
            this.getScheduledThreadPoolExecutor().setExecuteExistingDelayedTasksAfterShutdownPolicy(false);
            super.destroy();
        }
    };
    scheduler.setWaitForTasksToCompleteOnShutdown(true);
    scheduler.setAwaitTerminationSeconds(60);
    return scheduler;
}

原文地址,我搜索了一圈没找到答案,特此记录下。

### RecExecutor 超时终止问题的解决方案 当 RecExecutor 遇到超时终止问题时,通常是因为任务未能在指定时间内完成,或者系统状态异常导致线程池无法正常关闭。以下是针对该问题的详细分析和解决方法: #### 1. 延迟重试机制 如果超时是由常见的连接性问题或系统繁忙引起的,则可以考虑引入延迟重试机制。应用程序应在重试请求前等待一段时间,以便工作队列或流量得以清理[^1]。通过这种方式,可以有效减少因瞬时负载过高而导致的任务失败。 #### 2. 系统状态检查 在某些情况下,RecExecutor 的超时可能是由于系统异常终止导致的。例如,引用中提到的实例可能因异常终止而触发系统状态转储请求 (System state dump)[^2]。在这种场景下,建议检查日志以确认是否存在类似的异常终止事件,并确保系统资源(如内存、CPU)充足。 #### 3. 断路器模式的应用 为了增强系统的容错能力,可以在 RecExecutor 中实现断路器模式。断路器模式能够帮助应用程序限制意外故障的影响,例如部分失去连接性或服务完全失败的情况[^3]。当检测到多次连续失败时,断路器将自动切换到“打开”状态,阻止后续请求进入故障区域,从而避免进一步的资源浪费。 #### 4. 配置合理的内存和 CPU 限制 如果 RecExecutor 运行在容器化环境中,确保为 Pod 设置了适当的内存和 CPU 限制是至关重要的。未设置这些限制可能导致资源争用,进而影响任务执行效率[^3]。合理配置资源限制可以帮助避免因资源不足而导致的任务超时。 #### 5. 使用路径 MTU 发现机制 在网络通信中,数据包大小可能受到 MTU(最大传输单元)的限制。如果中间网络的 MTU 较小,可能会导致数据分片,从而增加延迟并引发超时问题[^4]。为避免这种情况,可以启用路径 MTU 发现机制,确保发送的数据包不会超过网络允许的最大尺寸。 #### 示例代码:实现延迟重试与断路器结合的解决方案 以下是一个简单的 Python 示例,展示了如何结合延迟重试和断路器模式来处理 RecExecutor 的超时问题: ```python import time from circuitbreaker import CircuitBreaker # 定义断路器 circuit_breaker = CircuitBreaker(fail_max=3, reset_timeout=10) @CircuitBreaker装饰器 @circuit_breaker def execute_task(task): try: # 模拟任务执行 time.sleep(2) # 假设任务需要2秒完成 return "Task completed" except Exception as e: raise e def retry_with_delay(func, max_retries=5, delay=2): retries = 0 while retries < max_retries: try: return func() except Exception as e: print(f"Attempt {retries + 1} failed: {e}") retries += 1 time.sleep(delay) raise TimeoutError("Max retries reached") # 执行任务并应用延迟重试 result = retry_with_delay(lambda: execute_task("Sample Task")) print(result) ``` #### 总结 通过引入延迟重试机制、检查系统状态、应用断路器模式以及合理配置资源限制,可以有效解决 RecExecutor 的超时终止问题。同时,确保网络通信中的 MTU 配置正确,也能避免因数据分片导致的延迟。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值