抢购倒计时应选 System.nanoTime() 而非 currentTimeMillis()，因其高精度、单调递增且不受系统时钟调整影响；需配合 currentTimeMillis() 基准时间计算剩余时间，并用 AtomicLong 保证线程安全。
为什么不用 System.currentTimeMillis() 而选 System.nanoTime()
因为抢购场景对时间精度和单调性要求极高：System.currentTimeMillis() 可能被系统时钟调整（NTP 同步、手动改时间）导致跳变或回拨，造成倒计时错乱甚至“未开始就结束”；System.nanoTime() 基于高精度、单调递增的纳秒级计时器，不受系统时钟干扰，适合做相对时间差计算。
但它不表示“真实世界时间”，不能直接转成 HH:MM:SS 显示——得配合一个基准时间戳来算剩余秒数。
- 只用
System.nanoTime()做差值，别试图格式化它本身 - 启动倒计时那一刻，记下
System.currentTimeMillis()作为显示基准，再用System.nanoTime()持续测耗时 - 避免在循环里反复调用
System.nanoTime()做加法累加（浮点误差+性能损耗），应每次用当前值减初始值
怎么写一个线程安全的倒计时核心逻辑
抢购倒计时不是纯 UI 动画，要支撑多线程检查库存、拦截请求、触发下单。核心状态（剩余毫秒数、是否已结束）必须原子更新。
别用 int 或 long 字段配 synchronized 块——锁粒度大、易阻塞；推荐 AtomicLong 存剩余毫秒，并用 CAS 更新。
立即学习“Java免费学习笔记（深入）”；
- 初始化时：用
System.currentTimeMillis()算出绝对截止时间endTimeMs，再用System.nanoTime()记录起始纳秒startNanos - 每次检查剩余时间：用
System.nanoTime() - startNanos算出已过纳秒 → 转毫秒 → 用endTimeMs - 已过毫秒得剩余毫秒 - 用
AtomicLong.compareAndSet(old, new)更新剩余值，确保并发读写不丢状态 - 一旦剩余 ≤ 0，立刻用
compareAndSet(0, 0)锁死状态，防止重复触发结束逻辑
System.nanoTime() 在 Linux / Windows 上的实际精度差异
它不保证是“真纳秒级”——底层依赖 OS 提供的高精度计时器（Linux 的 CLOCK_MONOTONIC，Windows 的 QueryPerformanceCounter）。实际分辨率通常在 10–15 微秒（Linux）或 0.5–15 微秒（Windows），远高于毫秒级需求，但别指望每个调用都返回唯一递增值。
- 连续两次
System.nanoTime()调用可能返回相同值（尤其在短循环中），所以不要靠“值是否变化”判断时间推进 - 别用它做超短间隔（LockSupport.parkNanos() 或
Thread.sleep()的事 - JVM 启动参数
-XX:+UsePreciseTimer（HotSpot 旧版）已废弃，现代 JDK 默认启用高精度，无需额外配置
抢购结束那一刻的竞态问题怎么防
倒计时归零 ≠ 所有请求立即失效。网络延迟、JVM 指令重排、缓存可见性都可能导致“看到剩余 1ms 的请求，实际提交时已超时”。
关键不是“显示剩多少”，而是“能否下单”。所有业务入口（HTTP 接口、消息队列消费者）必须实时查剩余时间，且该查询需基于同一份 AtomicLong 状态，不能依赖本地缓存或上一次读取结果。
- 每次下单前，调用
getRemainingMs()方法（内部用System.nanoTime()实时计算），结果 ≤ 0 则拒绝 - Redis 分布式环境下，不能只靠本地
AtomicLong，得用 Lua 脚本原子扣减库存 + 校验时间戳，否则多实例间状态不同步 - 前端显示的倒计时可异步轮询，但后端校验必须独立、强一致——显示和执行永远是两套逻辑
真正难的不是算时间差，而是让“时间感知”穿透整个调用链：从定时任务触发、到网关限流、再到数据库行锁，每层都得拿到同一份单调、可信、低延迟的时间视图。稍有松动，就会出现“看着还有 2 秒，但提示已结束”的情况。
