System.currentTimeMillis()在秒杀风控中用于时间窗口限流、防重放和熔断判断，核心是利用其高精度、低开销、全局单调递增特性构建规则，而非单纯计时；需规避时钟回拨、不可作ID、跨服务比对需统一时间源。
用 System.currentTimeMillis() 构建秒杀风控拦截防线，核心不是靠它“计时”，而是利用其高精度、低开销、全局单调递增的特性，做时间窗口判定、请求频控、防重放和行为时效校验。关键在于：它只是时间戳“原料”，真正起作用的是你围绕它设计的规则和结构。
基于时间窗口的请求频次拦截
秒杀场景下，同一用户/设备/IP 在极短时间内高频请求，大概率是脚本或外挂。用 currentTimeMillis() 可快速实现滑动窗口或固定窗口限流：
- 维护一个线程安全的 Map（如
ConcurrentHashMap<string queue>></string>），Key 是用户 ID 或设备指纹，Value 是该实体最近 N 次请求的时间戳队列 - 每次请求到来时，调用
System.currentTimeMillis()获取当前毫秒时间戳，清理队列中早于now - windowMs的旧记录（例如 windowMs = 1000 表示 1 秒窗口） - 若清理后队列长度 ≥ 阈值（如 5 次/秒），则拦截并返回“请求过于频繁”
- 注意：单机限流有局限，生产环境需配合 Redis 实现分布式窗口（如用 ZSET 存时间戳+score，
ZREMRANGEBYSCORE清理过期项）
毫秒级请求时效性校验（防重放）
客户端在请求中携带一个 timestamp 参数（由前端调用 Date.now() 生成），服务端用 currentTimeMillis() 校验其新鲜度：
- 接收请求后立即获取服务端当前毫秒时间戳：
long serverTime = System.currentTimeMillis() - 解析客户端传入的
timestamp（需校验是否为合法 long 值，且非未来时间） - 计算偏差：
long diff = Math.abs(serverTime - clientTimestamp) - 若
diff > 3000（即超过 3 秒），拒绝请求——既防网络延迟过大导致的误伤，也防攻击者截获旧请求重放 - 建议配合一次性 nonce 或签名，避免 timestamp 被复用
本地熔断与快速失败判断
在秒杀入口做轻量级“自适应熔断”，避免流量洪峰压垮下游。利用 currentTimeMillis() 记录关键节点耗时，动态调整放行策略：
- 在拦截器中记录进入时间：
long start = System.currentTimeMillis() - 执行核心校验逻辑（如库存检查、用户资格）后，计算耗时：
long cost = System.currentTimeMillis() - start - 若最近 10 次平均耗时 > 200ms，或失败率 > 30%，可临时开启“快速拒绝”模式：对非高优先级用户直接返回“系统繁忙”，不走完整链路
- 该机制依赖毫秒级精度感知响应恶化，比秒级统计更敏感，适合秒杀这种瞬时压力场景
规避 currentTimeMillis 的常见陷阱
currentTimeMillis() 虽好，但直接用容易翻车：
- 它受系统时钟影响，NTP 校准可能导致时间回拨（比如从 10:00:00.500 突然跳回 10:00:00.200），破坏单调性。关键逻辑中建议搭配
System.nanoTime()做相对耗时测量，或使用java.time.Clock抽象封装可测试性 - 不要用它生成唯一 ID（如订单号），因并发下可能重复；需结合机器 ID、序列号等
- 跨服务调用时，不同机器时钟不同步，不能直接比对双方的
currentTimeMillis()值，应统一以网关或认证中心时间为准 - 日志中打时间戳建议用
Instant.now()，语义更清晰，且便于时区处理
