System.nanoTime() 是 Java 中唯一能天然规避系统时间回拨的计时工具，它基于 CPU 高精度计数器持续累加，值严格递增且不受系统墙钟调整影响；而 currentTimeMillis() 直接映射操作系统时钟，遇回拨、前跳或闰秒易导致负差值、批量触发或校验失效；凡依赖“经过多久”的场景（如超时控制、微秒压测、抢购倒计时、环形缓冲排序）均应改用 nanoTime；使用时须遵守三约束：仅用于差值计算、两次调用需紧邻、单位换算用整除。
System.nanoTime() 是 Java 中唯一能天然规避系统时间回拨的计时工具。它不读取系统墙钟，而是基于 CPU 高精度计数器（如 TSC 或 CLOCK_MONOTONIC）持续累加，只要 JVM 没重启，值就严格递增——不会倒流、不会突跳，哪怕运维半夜手动把系统时间往回调 5 分钟，它也完全不受影响。
为什么 currentTimeMillis() 在回拨时会出问题
System.currentTimeMillis() 返回的是“墙上时间”，直接映射操作系统时钟。一旦发生 NTP 校准或人工改时：
- 回拨场景：比如当前是 10:00:00.500，被调成 09:55:00.000，两次调用差值可能变成负数，导致超时逻辑误判
- 前跳场景：时间突然快进 2 秒，定时任务可能批量触发，会话过期校验提前失效
- 闰秒或微调：Linux 内核的 adjtimex 调整也可能引发毫秒级抖动，影响高频判断
哪些业务必须用 nanoTime 替代 currentTimeMillis
凡是依赖“经过多久”而非“现在几点”的逻辑，都该切换：
- 串口/网络通信超时控制：500ms 超时不能因系统调时失效，应锚定单次 start 值做减法
- 微秒级性能压测：算法耗时在 1–100 微秒区间，currentTimeMillis() 多次调用常返回相同值
- 抢购倒计时器：循环中靠累加毫秒易受浮点误差和跳变累积偏移，nanoTime 只做一次减法，无漂移
- 环形缓冲区采样排序：要求时间戳严格单调，不能出现相等或倒序样本
正确使用 nanoTime 的三个硬约束
不是调两次再相减就安全，踩错任一条件都会让优势归零：
立即学习“Java免费学习笔记（深入）”；
- 只用于差值，禁止存储或跨线程传递：nanoTime 值本身无物理意义，不能打印、序列化、存数据库、传给其他 JVM
- 两次调用要尽可能紧邻：中间避免 GC、锁等待、日志输出等长延迟操作；高频测量可用 ThreadLocal 缓存起始值
- 单位换算用整除，不用浮点舍入：转毫秒写 nanos / 1_000_000，别用 Math.round(nanos / 1_000_000.0)，避免不可控舍入误差
典型安全写法示例
以串口通信超时为例，全程不碰系统时间：
long start = System.nanoTime();
int timeoutNanos = 500_000_000; // 500ms
while (!dataReceived && (System.nanoTime() - start) < timeoutNanos) {
// 等待数据
}
if (!dataReceived) {
throw new TimeoutException("No response within 500ms");
}关键点：整个逻辑只依赖一个 start 值，所有判断都是 当前 nanoTime 减去 start，彻底脱离系统时钟。
