system.nanotime()的核心价值在于单调性而非纳秒精度，它保证同一jvm内时间值只增不减、不受系统时钟调整影响，是超时控制、性能测量等场景的可靠基础。
System.nanoTime() 的核心价值不在“纳秒”这个单位，而在它天然具备的单调性——同一 JVM 进程内，值只增不减，不受系统时间扰动。这使得它成为超时控制、性能测量、延迟敏感逻辑的底层计时基石。
为什么单调性比“精度”更重要
很多人关注 nanoTime() 能否测出 10 纳秒的操作，却忽略了更关键的一点：即使分辨率只有 10 微秒，只要两次调用的差值稳定、不回跳，就能可靠判断“是否超时”或“哪段更快”。而 currentTimeMillis() 在 NTP 校准或手动改时后可能突降 5 秒，导致定时任务误触发、缓存提前失效、连接被错误断开。
- 单调性保障的是逻辑正确性，不是数字好看；精度影响的是测量粒度，不是行为稳定性
- 系统时钟跳变是运维常态，不是异常场景；nanoTime() 的设计就是为应对这种常态
- 差值（end - start）恒 ≥ 0，且随真实耗时线性增长——这是所有健壮计时逻辑的底线
超时控制中如何真正用好单调性
把 nanoTime() 当成一个不依赖外部世界的“本地跑表”，整个超时逻辑必须锚定在同一个起点上，全程不引入任何 wall-clock 时间。
- 初始化一次 start = System.nanoTime()，后续所有判断都基于 start 的差值
- 避免混合使用 currentTimeMillis() 做条件分支，例如“超时且当前时间是白天”这类逻辑会破坏单调性优势
- 休眠后重新计算剩余时间：remaining = timeoutNs - (System.nanoTime() - start)，而不是重设 start
- 注意 Thread.sleep() 本身不保证精确时长，但 nanoTime() 能准确反映实际挂起时间，可用于补偿校准
性能对比时单调性带来的可比性保障
两个算法 A 和 B 的耗时对比，本质是比较 (endA - startA) 与 (endB - startB)。只要它们运行在同一 JVM 内，nanoTime() 提供的差值就具备跨方法、跨线程（非极短间隔）、跨 GC 周期的可比基础。
- 无需担心某次测量期间系统时间被回拨 1 秒，导致 A 的耗时看起来比 B 少 1000 毫秒
- JIT 编译、类加载等一次性开销不影响差值语义，只要预热充分，差值反映的就是纯业务执行时间
- 多轮采样取中位数时，所有样本都来自同一单调序列，统计结果不会因外部时钟抖动而失真
- 容器或云环境中，宿主机时间调整完全隔离，应用计时行为保持一致
哪些地方容易悄悄破坏单调性优势
单调性不是自动生效的魔法，错误用法会让它形同虚设。
- 跨 JVM 比较：把本机 nanoTime() 值发给另一台机器做判断，数值无意义
- 混用时间源：在超时逻辑中穿插 currentTimeMillis() 判断，等于主动引入回拨风险
- 误当时间戳：把 nanoTime() 绝对值存入数据库或日志，后续无法解析、不可读、无业务含义
- 忽略测量开销：对低于 100 纳秒的操作直接单次测量，结果主要是计时器自身噪声，不是真实耗时
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
