用@Scheduled执行定时任务，如何避免集群的并发问题

面试记录 2026-10-14

题目：用 @Scheduled 执行定时任务，如何避免集群的并发问题？

难度：medium

标签：practice/java, java/concurrency, spring/scheduling

评分：⭐⭐⭐⭐☆（4/5）

我的回答

首先，集群了为什么要使用单机的计划任务,这里应该去使用分布式调度任务平台,比如 xxljob 之类的;

如果一定要用单机计划任务那你就要考虑任务执行的幂等性了。首先确认这个任务是否是幂等的，它执行多次是否会有不同的影响。如果没有，那么就简单的控制做一个锁。这个任务在执行节点时候，通过类似于 Redis 锁这种分布式锁去控制，这个任务已经执行了，在这个节点已经执行了。执行过后，其他执行中的其他节点在执行的时候判定一下，如果当前已经在执行或者已经执行完了，其他节点不再二次执行，防止并发。

核心其实有很多可以处理的，比如说任务状态、任务记录，然后换成 Redis 锁，都可以处理这个问题。比如执行，执行完任务，在这个节点就查一条日志，下次执行前就查询数据库是否有这个日志。其他任务同时间做一个锁，执行的时候就是，有这个日志大家就不执行了，没这个日志的，就第一个就执行，就结束了，就可以控制这个问题。

而第一个要给计划任务加锁，防止并发。第二个就是做密等。当然不做密等的话，就做控制，控制限定，然后判定执行了，当前这个时间节点要求执行的执行了，其他就不执行。就能解决相应的问题。

点评

优点：

• 第一个判断很关键：应该用分布式调度平台（xxl-job）而不是硬凑单机任务
• 抓到了核心思路：分布式锁 + 幂等性组合
• 覆盖了两种策略：幂等（任务记录日志表）+ 分布式锁（Redis 锁）
• 有分场景意识：先判断任务是否幂等，再决定加锁还是做幂等

不足：

• 未提分布式锁的实现细节：TTL 陷阱（业务执行超过 TTL 锁失效）、Redisson 看门狗机制、RedLock 争议
• 未提 xxl-job 的核心机制：分片广播、失败重试、执行器心跳、路由策略、阻塞处理策略
• 未提 @Scheduled 的单机坑：默认单线程串行、fixedRate vs fixedDelay 语义、TaskScheduler 线程池
• 未提其他分布式调度方案：Elastic-Job、Quartz JDBC store、阿里云 SchedulerX

补充：

• 分布式锁三要素：原子性（SET key value NX PX 30000）、唯一性（value 用 UUID 防误删）、续期（Redisson 看门狗 30s 续期）
• TTL 陷阱：业务执行超过 TTL → 锁失效 → 其他节点获取锁 → 并发执行；解法是看门狗续期或业务执行前检查锁是否还在
• xxl-job 核心机制：
• 分片广播：多节点按 shardIndex/shardTotal 分片执行
• 阻塞策略：覆盖（后触发覆盖前）、丢弃（后触发丢弃）、排队（串行执行）
• 路由策略：轮询、一致性哈希、故障转移、执行器繁忙度
• 失败重试：支持配置重试次数 + 重试间隔
• 其他方案：
• Elastic-Job（ShardingSphere）：分片 + 弹性扩缩
• Quartz JDBC store：QRTZ_LOCKS 表行级锁，简单但扩展性差
• 阿里云 SchedulerX / 腾讯云 TAT：托管服务，无需自维护

完整讲解

第一部分：知识重点剖析

核心考点定位：考察"单机调度"到"分布式调度"的架构演进，以及分布式锁的工程化细节。

知识点拆解：

1. @Scheduled 的单机局限：

• 默认单线程（ScheduledExecutorService 单线程），多个任务串行
• fixedRate 是"从上次开始计"，fixedDelay 是"从上次结束计"，语义不同
• 无执行日志、无失败重试、无告警、无路由

1. 分布式锁三大陷阱：

• TTL 陷阱：业务执行超过 TTL → 锁失效 → 并发；解法：Redisson 看门狗（默认 30s 续期）
• 误删陷阱：A 节点锁超时释放，B 节点获取锁，A 执行完误删 B 的锁；解法：value 用 UUID，删除前 CAS 校验
• 主从切换陷阱：Redis 主节点写锁，未同步到从节点就宕机，从节点选主后锁丢失；解法：RedLock（有争议，Martin Kleppmann 反对）

1. xxl-job 核心机制：

• 分片广播：shardIndex/shardTotal 分片执行，天然避免并发
• 阻塞策略：覆盖（DispatcherTimeOut 触发覆盖）、丢弃（后触发丢弃）、排队（FIFO 串行）
• 路由策略：轮询、一致性哈希（同 shard 路由到同节点）、故障转移、执行器繁忙度
• 执行器心跳：每 10s 心跳，调度中心检测执行器健康

1. 方案对比：

• Redis 分布式锁：轻量、简单、TTL 陷阱；适合单机任务临时上锁
• xxl-job：功能全、生态好、有 UI、有告警；适合生产级定时任务
• Elastic-Job：分片能力强、弹性扩缩；学习曲线陡
• Quartz JDBC store：简单、无需外部依赖；扩展性差、锁竞争

1. 兜底策略：即使锁失效，业务幂等（唯一索引 + 状态机）要能兜住

第二部分：考察方向与延伸递进

考察方向：

• 深度：Redis 分布式锁的原子性实现（Lua 脚本）、RedLock 的争议、Redisson 看门狗原理
• 广度：与 Quartz、Elastic-Job、SchedulerX 的对比；Cron 表达式 vs Quartz Cron
• 应用：大数据 ETL 调度（Airflow/DolphinScheduler）、任务血缘、失败补偿

延伸递进面试题：

1. Redis 分布式锁的 TTL 怎么设置合理？

• 解答要点：一般 30s + 看门狗续期；业务执行时间远超 TTL 时要评估是否真的需要锁（可能任务本身设计有问题）

1. xxl-job 分片广播和 Quartz JDBC store 有什么区别？

• 解答要点：xxl-job 是"分片执行"（每个节点执行自己那份），Quartz 是"单点执行"（多节点竞争同一份任务，靠锁选出一个）；前者扩展性好，后者简单

1. 如果任务执行时间超过锁 TTL，怎么保证不并发？

• 解答要点：Redisson 看门狗自动续期（默认 30s）；业务执行前检查锁是否还在（CAS 校验 value）；业务结束释放锁时再次 CAS 校验

第三部分：面试者参考回答（三步法口语化，300-400 字）

【一句话结论】

面试官您好，单机 @Scheduled 在集群下必然并发，首选上分布式调度平台（xxl-job）；如果一定要在 @Scheduled 上救场，就用"分布式锁 + 业务幂等"组合拳。

【三点展开】

第一，先判断该不该用 @Scheduled：如果是生产级定时任务（有重试、告警、分片需求），直接上 xxl-job，它有分片广播（多节点分片执行）、阻塞策略（覆盖/丢弃/排队）、路由策略（轮询/一致性哈希）、失败重试、执行日志，单机 @Scheduled 缺的功能它都有。

第二，如果一定要 @Scheduled + 分布式锁：用 Redisson RLock 而不是裸 Redis SETNX，Redisson 有看门狗机制（30s 自动续期）解决 TTL 陷阱，value 用 UUID + CAS 校验防误删。锁的粒度要按业务场景选：全局唯一锁（任务级）、hash 分片锁（数据级）。锁竞争高时降级到数据库 CAS（UPDATE task_lock SET locked_by=? WHERE status='free' AND expire_time>?）。

第三，锁失效的兜底是业务幂等：任务处理的数据写入用唯一索引（unique key on biz_id），状态机用乐观锁 SQL（UPDATE ... WHERE status=?）。即使锁失效并发执行了，业务层也能兜住不重复处理。锁是"防并发"，幂等是"防重复"，两者组合才完整。

【一句边界】

当然，如果是分钟级以上的低频任务，甚至可以用"数据库唯一索引 + 时间窗口"做最简锁（INSERT INTO task_log(task_name, exec_time) VALUES(?, ?) ON DUPLICATE KEY UPDATE ...），不用引入 Redis 依赖——KISS 原则，能用数据库解决的别引入新组件。