保障Java定时任务幂等性的核心是“识别重复执行+阻断重复处理”，需结合唯一业务标识与状态机、分布式锁、条件化DML及补偿监控机制。
在 Java 定时任务中保障事务的幂等性，核心不是靠事务本身（ACID 的原子性不等于幂等），而是靠“识别重复执行 + 阻断重复处理”的组合机制。定时任务天然存在重试、调度漂移、集群多实例触发等风险，一旦任务逻辑涉及数据库写入、消息发送或外部调用，就必须主动设计幂等防线。
用唯一业务标识 + 状态机控制执行入口
每次定时任务启动时，先查一条与本次业务强绑定的唯一记录（如订单超时关单任务，用 order_id + job_type 作联合主键或唯一索引）。若该记录已存在且状态为“已处理”，直接 return；否则插入占位记录并标记为“处理中”，再执行后续业务逻辑，最后更新为“已完成”。这相当于把幂等判断下沉到数据库层面，利用唯一约束拦截重复插入。
- 推荐表结构：job_execution_log (id, biz_key, job_type, status, created_at, updated_at)
- 关键操作：INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，避免先查后插的竞态
- 注意：status 字段需支持“处理中→已完成”或“处理中→失败”两类流转，便于排查卡住的任务
结合分布式锁限制同一任务仅被一个节点执行
在集群环境下，多个定时实例可能同时触发同一任务。此时仅靠数据库唯一键不够——因为插入可能发生在不同节点、微秒级时间差内。需叠加分布式锁（如 Redis SETNX + 过期时间）作为第一道闸门：
- 生成锁 key：例如 lock:close-order:20260820（按日期分片可降低热点）
- 加锁成功才进入 DB 幂等校验环节；加锁失败立即跳过
- 锁过期时间必须明显长于单次任务最大执行耗时，防止误释放
让业务操作自身具备幂等语义
事务内的 DML 操作尽量避开“无条件 INSERT”或“无条件 UPDATE”，改用带条件的变更：
立即学习“Java免费学习笔记（深入）”；
- 扣减库存：UPDATE inventory SET stock = stock - 1 WHERE order_id = ? AND stock >= 1 AND status = 'locked'
- 更新订单状态：UPDATE orders SET status = 'closed' WHERE id = ? AND status = 'unpaid'
- 发通知类操作：先查是否已发（via notice_log 表），再决定是否调用短信/邮件 SDK
补偿与可观测性不能少
幂等不是万能保险。要接受极小概率下“锁失效+DB冲突漏判”的情况，并提前准备兜底手段：
- 所有定时任务日志必须包含 biz_key 和 execution_id，方便快速定位重复执行链路
- 对关键业务（如关单、退款），增加异步对账任务，扫描异常状态并触发人工介入或自动补偿
- 监控维度：任务执行次数 vs 成功次数 vs 被幂等拦截次数，三者比例突变即告警
