应优先使用 System.nanoTime() 测量耗时，因其基于高精度计数器、不受系统时钟调整影响、分辨率达纳秒级；而 currentTimeMillis() 仅适用于挂钟时间，存在精度低（10–16ms）、易受NTP调整/虚拟机暂停等干扰、混入非业务耗时等问题。
用 System.currentTimeMillis() 做耗时测量，简单直接，但跨系统调用（比如 HTTP 请求、数据库访问、RPC）时，它容易给出“看似合理实则失真”的结果——不是代码写错了，而是它的精度和语义本身就不适合这类场景。
为什么 currentTimeMillis() 的差值常被误用
System.currentTimeMillis() 返回的是自 1970-01-01 00:00:00 UTC 起的毫秒数，底层依赖操作系统的时间源（如 Linux 的 gettimeofday() 或 Windows 的 GetSystemTimeAsFileTime）。它的设计目标是**表示 wall-clock 时间（挂钟时间）**，不是高精度计时器。这意味着：
- 分辨率通常只有 10–16ms（取决于 OS 和硬件），短于这个间隔的耗时可能全显示为 0 或跳变 15ms
- 系统时钟可能被 NTP 同步、手动调整、虚拟机暂停等事件回拨或跳跃，导致差值为负或异常偏大
- 它不区分线程调度延迟、GC 暂停、IO 阻塞等“非业务耗时”，但这些在跨系统调用中占比极高
跨系统调用时的典型失真案例
假设你测一次远程 HTTP 请求：
long start = System.currentTimeMillis();
String resp = httpClient.get("https://api.example.com/data");
long end = System.currentTimeMillis();
System.out.println("耗时：" + (end - start) + "ms");
表面看逻辑没问题，但实际结果可能：
- 真实网络往返 8ms，却打印出 0ms（低于系统时钟粒度）
- 请求期间触发了 200ms 的 Full GC，结果报出 215ms —— 你以为是服务慢，其实是 JVM 卡住了
- 服务器响应极快（2ms），但客户端线程被调度器延迟 30ms 才拿到结果，最终显示 32ms
更靠谱的替代方案：优先用 nanoTime()
对纯代码段或单机内耗时分析，System.nanoTime() 是更好的选择：
- 基于高精度计数器（如 CPU TSC），分辨率通常达纳秒级（实际可用精度约 100ns–1μs）
- 不受系统时钟调整影响，只反映“经过的物理时间”，适合测量间隔
- 注意：它不能转成绝对时间，也不能跨 JVM 进程比对，但测耗时完全够用
改写上面的例子：
long start = System.nanoTime();
String resp = httpClient.get("https://api.example.com/data");
long end = System.nanoTime();
long durationMs = (end - start) / 1_000_000;
System.out.println("耗时：" + durationMs + "ms");
真正需要关注跨系统调用时的“端到端”精度
即使用了 nanoTime()，跨系统调用的耗时仍含大量不可控变量。要准确定位瓶颈，得结合多维度观察：
-
服务端打点：在 API 入口/出口用
nanoTime()记录处理耗时，排除网络和客户端干扰 -
网络层分离：用
curl -w "@format.txt"或 Wireshark 看 TCP 建连、TLS 握手、首字节（TTFB）、传输完成等分段耗时 - 采样而非单次：单次测量意义很小，应统计 100+ 次调用的 P50/P95/P99，并剔除明显离群值（如 >1s 的请求可能是 GC 或 IO 阻塞）
-
避免日志干扰：不要在耗时统计前后插入同步日志（尤其是
System.out.println），它们自身可能阻塞并扭曲结果
不复杂但容易忽略：测耗时不是为了得到一个数字，而是为了识别瓶颈在哪里。用对工具，再结合上下文，才能让那个数字真正说话。
