System.nanoTime()专用于高精度耗时测量，分辨率通常达微秒级且单调递增；System.currentTimeMillis()用于获取系统时间戳，精度为毫秒但可能跳变或回退。
System.nanoTime() 和 System.currentTimeMillis() 的精度差异，不是简单“纳秒 vs 毫秒”的单位换算问题，而是底层机制、设计目标和实际可用分辨率的根本不同。
精度本质不同
currentTimeMillis() 返回的是“墙上时间”（wall-clock time）的毫秒近似值，它本质上是操作系统提供的时间快照。它的精度受限于系统时钟中断频率：Windows 通常为 15.6ms，Linux 一般为 1–10ms，macOS 约 1ms。这意味着即使代码执行仅需几十微秒，连续两次调用 currentTimeMillis() 也可能返回完全相同的值——它根本“看不见”这个时间变化。
nanoTime() 返回的是一个单调递增的计数器值，单位是纳秒，但关键在于它背后使用的是高分辨率时钟源（如 Windows 的 QueryPerformanceCounter、Linux 的 CLOCK_MONOTONIC）。现代系统上，其实际分辨率通常在 10–100 纳秒之间，能稳定分辨微秒级甚至亚微秒级的耗时差异。
稳定性与可靠性差异
- currentTimeMillis() 可能倒流：系统时间被 NTP 校准或手动修改时，前后两次调用结果可能变小，导致计算出负的耗时
- nanoTime() 保证单调性：后续调用值一定 ≥ 之前调用，不会因系统时间调整而跳变或回退
- currentTimeMillis() 的值可跨 JVM/机器比较（都是 Unix 时间戳），nanoTime() 的绝对值无跨实例意义，只用于同一次 JVM 内的差值计算
实际测量中谁更“准”？
对“执行一段代码花了多久”这个问题，nanoTime() 是唯一合理的选择：
- 毫秒级 API 在测量小于 10ms 的操作时，误差常达 50% 以上；测微秒级逻辑（如 HashMap 查找、锁争用）时，currentTimeMillis() 基本无法给出有效数据
- nanoTime() 单次调用开销约 20–50 纳秒，对多数业务逻辑影响可忽略；但若待测逻辑本身仅几十纳秒，需多次运行取统计值，否则结果易受噪声干扰
- 注意：nanoTime() 的“纳秒”是返回单位，不等于硬件能稳定分辨 1 纳秒——实际有效分辨率取决于 OS 和 CPU，通常在 10–100 纳秒量级
别混淆“精度”和“用途”
两者不是“高低配”，而是“不同工种”：
- 需要知道“现在几点”“日志打个时间戳”“设置 5 秒后超时” → 用 currentTimeMillis()
- 需要知道“这段代码到底跑多快”“两个算法哪个更快”“压测 P99 延迟是多少纳秒” → 必须用 nanoTime()
- 拿 nanoTime() 去算“当前时间”、存数据库当时间戳、传给 Thread.sleep() —— 这些都属于误用，会引发逻辑错误
