System.nanoTime()能规避时钟回拨因其基于CPU高精度计数器、单调递增且不依赖系统墙钟；适用于超时控制、性能压测、倒计时器、环形缓冲区等对时间顺序和精度敏感的场景。
System.nanoTime 为什么能规避时钟回拨
因为 System.nanoTime() 不读系统墙钟，它基于 CPU 的高精度计数器（如 TSC），只返回从 JVM 启动后经过的纳秒数。系统时间被 NTP 校正或人工修改时，System.nanoTime() 完全不受影响——它天生单调递增，不会跳变、不会倒流。
哪些业务场景必须用 nanoTime 替代 currentTimeMillis
以下情况若误用 System.currentTimeMillis()，会导致逻辑错误或统计失真：
- 超时控制：比如串口通信中设置 500ms 超时，若中途系统时间被回拨 2 秒，
currentTimeMillis()计算出的“已过时间”可能突变为负值，直接触发假超时 - 性能压测：单次调用耗时在微秒级，
currentTimeMillis()返回值不变，差值恒为 0 - 倒计时器（如抢购）：循环中依赖累加毫秒数会因浮点误差和时钟跳变逐步偏移，而
System.nanoTime()只做一次减法，无累积误差 - 环形缓冲区采样时间戳：要求严格顺序，不能出现相等或倒序的样本时间
正确使用 nanoTime 的三个硬约束
不是调用两次再相减就万事大吉，踩错任意一条都会让单调性优势归零：
-
System.nanoTime()的返回值本身无物理意义，禁止存储、打印、序列化、跨 JVM 传递；只允许同一线程内两次调用后做减法 - 两次调用必须尽可能靠近，避免中间插入 GC、线程挂起、锁竞争等长延迟操作；高频测量建议用
ThreadLocal<long[]>缓存起始值 - 差值结果仍是纳秒单位的
long，后续转毫秒请用nanos / 1_000_000（整除），而非Math.round(nanos / 1_000_000.0)—— 避免浮点运算引入不可控舍入
Android USB 串口超时管理的典型写法
这是最容易暴露时钟回拨问题的场景之一。下面这段代码把单调性真正用到了实处：
long start = System.nanoTime();
int timeoutNanos = 500_000_000; // 500ms
while (!dataReceived && (System.nanoTime() - start) < timeoutNanos) {
// 短暂休眠避免空转
try {
Thread.sleep(1);
} catch (InterruptedException e) {
break;
}
}
boolean timeout = (System.nanoTime() - start) >= timeoutNanos;注意：这里没有用 System.currentTimeMillis() 做任何判断，整个循环生命周期都锚定在单一 start 值上。即使设备在通信中途被手动校时，超时逻辑依然精准可靠。
真正难的不是调用 System.nanoTime()，而是把所有依赖“经过时间”的逻辑路径都统一收束到一次起始采样 + 差值计算的范式里。漏掉一个分支，就可能在某个凌晨三点的 NTP 同步时刻突然崩掉。
