system.currenttimemillis() 是构建过期判定最常用、最可靠的时间基准，用于记录起始时间并计算当前时间与起始时间的差值是否超过预设阈值，但需配合 ntp 同步、版本号、redis expire 等机制提升健壮性，不适用于分布式强一致性过期控制。
System.currentTimeMillis() 本身只是一个获取当前时间毫秒数的底层方法，它不直接实现业务过期逻辑，但它是构建过期判定最常用、最可靠的时间基准。
用时间戳记录操作发生时刻
在业务开始时（比如用户发起请求、生成令牌、创建缓存项），调用 System.currentTimeMillis() 获取当前毫秒值，并保存为“起始时间”或“创建时间”。
- 例如：用户登录后生成 token，同时记录 createTime = System.currentTimeMillis()
- 这个时间戳应和业务数据一起持久化（如存入数据库字段）或暂存（如放入 Redis 的 value 中）
计算是否过期：当前时间 - 起始时间 > 过期时长
需要判定时（比如每次接口校验 token、读取缓存前），再次调用 System.currentTimeMillis() 得到当前时间，与之前保存的起始时间做差，再与预设的过期阈值（单位：毫秒）比较。
- 示例：若 token 有效期为 30 分钟，则阈值为 30 * 60 * 1000 = 1800000L
- 判定逻辑：System.currentTimeMillis() - createTime > 1800000L → 已过期
- 注意使用 long 类型避免整型溢出
配合其他机制提升健壮性
单纯依赖时间戳判定存在边界问题（如系统时钟回拨、多节点时间不同步），建议结合以下方式：
- 服务端统一使用 NTP 同步时间，减少节点间偏差
- 对关键操作（如支付、库存扣减），增加版本号或状态字段，避免仅靠时间“误判”已失效的操作仍被处理
- 缓存场景优先使用 Redis 的 EXPIRE 命令，由存储层自动清理；Java 层的时间判断作为兜底或预检
不推荐直接用于分布式强一致性过期控制
在跨服务、多实例场景中，各 JVM 的 System.currentTimeMillis() 可能有几十毫秒差异，无法精确保证“同一毫秒全部失效”。此时应：
- 用分布式锁 + 统一时间源（如数据库 NOW() 或 TSO 服务）协调关键过期动作
- 或采用最终一致性设计：允许短暂窗口内“延迟过期”，通过异步任务定期清理+幂等校验来兜底
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
