定时器不导致任务积压，根源是提交节奏与执行能力不匹配；需结合拒绝策略（DiscardPolicy/DiscardOldestPolicy/CallerRunsPolicy/自定义AbortPolicy）、持久化补偿及上游降频熔断协同治理。

定时器本身不直接导致任务积压，真正的问题出在“用定时器反复提交任务，但线程池或执行器已无力消化”——这时必须靠合理的拒绝策略来兜底，而不是让任务越堆越多、内存暴涨、系统失稳。

明确积压根源：不是定时器错，是执行能力与提交节奏不匹配

很多团队发现“定时任务越跑越慢”“后台任务队列持续增长”，第一反应是调大线程池或加机器。但更关键的是先确认：

• 定时器触发频率是否远高于单次任务平均执行耗时（例如每秒触发，但任务平均耗时 800ms）
• 任务是否具备幂等性？重复提交会不会引发状态冲突？
• 当前线程池的队列类型是无界（如 LinkedBlockingQueue）还是有界？无界队列会掩盖问题，最终 OOM

四种标准拒绝策略怎么选？看业务语义

Java 线程池默认使用 AbortPolicy（抛 RejectedExecutionException），但它对定时任务场景往往不合适——异常若没被捕获，可能静默终止调度；若捕获后不做处理，又等于放任失败。

• DiscardPolicy：适合日志上报、埋点、健康检查等“丢了也不影响主流程”的任务。注意它完全静默，上线前务必配好监控指标（如 rejectedTaskCount）
• DiscardOldestPolicy：适合希望优先保障最新数据的场景，比如实时行情刷新、最新配置拉取。但要警惕老任务可能承载着不可跳过的中间状态
• CallerRunsPolicy：让定时线程自己执行被拒任务，可自然限流。但若定时线程是单线程调度器（如 ScheduledThreadPoolExecutor 的核心线程），会导致后续定时触发延迟，破坏时间精度
• AbortPolicy + 自定义包装：推荐用于关键定时任务。不直接用默认策略，而是包装一层，在抛异常前记录任务 ID、参数、堆栈，并触发告警

生产级方案：拒绝即持久化，再异步补偿

对不能丢、也不能阻塞的定时任务（如订单超时关单、优惠券过期清理），标准策略都不够用。此时应升级为“拒绝 → 持久化 → 补偿执行”闭环：

• 自定义 RejectedExecutionHandler，在 rejectedExecution() 中将任务参数（非 Runnable 对象本身）序列化存入 Redis 或 DB
• 搭配一个独立的补偿调度器（如 Spring @Scheduled(fixedDelay = 30_000)），定期扫描失败任务表，重新提交到线程池
• 任务对象需自带重试次数、最大尝试时间、业务唯一键，避免无限循环或重复执行

定时器侧配合：主动降频或熔断

拒绝策略是下游兜底，上游也得配合：

• 基于线程池的 getActiveCount() 和 getQueue().size() 做轻量健康判断，连续 N 次发现队列深度 > 阈值时，自动将定时器间隔从 5s 拉长到 30s
• 引入简单熔断器（如 Sentinel 的 SystemRule），当拒绝率超过 10% 持续 1 分钟，直接暂停该定时任务调度，人工介入后再恢复
• 对非强实时任务，改用“事件驱动+延迟队列”替代固定间隔定时器，例如用 Redis ZSET 或 RocketMQ 延迟消息，天然支持削峰