主题
面试速答（先看这里）
**一句话结论：**他山之石，可以攻玉，先看看xxl-job是咋解决的：
60秒标准回答：
在 Spring Boot 项目中， @Scheduled 默认在每个实例上都会执行一次任务。如果你的应用部署在 集群环境 下，所有节点都会执行 @Scheduled 任务，可能导致 并发问题
那么如何解决呢？
他山之石，可以攻玉，先看看xxl-job是咋解决的
**答题顺序：**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点
回答主线：
- **要点1：**在 Spring Boot 项目中， @Scheduled 默认在每个实例上都会执行一次任务。
- **要点2：**他是基于数据库的悲观锁，多个实例执行的时候，大家一起抢锁，谁抢到了谁执行。
- **要点3：**不管使用xxl-job这种select for update的悲观锁，还是基于Redis、Zookeeper来实现分布式锁，都是同样的思想，就是谁抢到锁，谁执行。
- **要点4：**但是需要注意，这里最好用非阻塞锁，抢锁失败就直接返回失败，而不是要一直等。
- **要点5：**那么，就可以用zookeeper，它能实现master选举的能力，任务执行的时候去选主，如果选举成功，则给他执行，否则就不执行。
**记忆锚点：**Scheduled → master → xxl-job → 悲观锁 → Scheduling → 基于数据库的悲观锁
易错提醒：
- 几种分布式锁实现方式如下： 但是需要注意，这里最好用非阻塞锁，抢锁失败就直接返回失败，而不是要一直等。
加分表达：
- 如果你的应用部署在 集群环境 下，所有节点都会执行 @Scheduled 任务，可能导致 并发问题。
- 那么，就可以用zookeeper，它能实现master选举的能力，任务执行的时候去选主，如果选举成功，则给他执行，否则就不执行。
追问准备：
- 围绕「Scheduled」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「master」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「xxl-job」：底层原理是什么？使用时有哪些边界和常见坑？
- 如果线上出现异常，你会如何定位、验证并规避？
典型回答
在 Spring Boot 项目中，@Scheduled 默认在每个实例上都会执行一次任务。如果你的应用部署在集群环境下，所有节点都会执行 @Scheduled 任务，可能导致并发问题。
那么如何解决呢？
他山之石，可以攻玉，先看看xxl-job是咋解决的：
他是基于数据库的悲观锁，多个实例执行的时候，大家一起抢锁，谁抢到了谁执行。
所以，我们也可以用悲观锁的思想。
不管使用xxl-job这种select for update的悲观锁，还是基于Redis、Zookeeper来实现分布式锁，都是同样的思想，就是谁抢到锁，谁执行。
几种分布式锁实现方式如下：
但是需要注意，这里最好用非阻塞锁，抢锁失败就直接返回失败，而不是要一直等。那么就可以用redis的tryLock代替lock。
除了加锁之外，还可以用另外一种方案，那就是选主
大家不妨想一下，其实是加分布式锁，谁抢到谁执行，这其实就是一种选主，大家一起选择一个master，谁是master谁执行。
那么，就可以用zookeeper，它能实现master选举的能力，任务执行的时候去选主，如果选举成功，则给他执行，否则就不执行。
除了以上方案外，再追问的话，就只能废弃到Scheduling Task这种用法了，用XXL-JOB、 Quartz 等框架代替。