System.currentTimeMillis() 不参与 NTP 同步，仅读取操作系统墙上时间；其“误差”实为系统时钟被 NTP 校正后的被动反映，跳变或负值源于 step 校正或时钟粒度限制。
System.currentTimeMillis() 本身不参与 NTP 时间同步，它只是读取操作系统当前的“墙上时间”（wall-clock time）。所谓“误差”，其实是它被动反映系统时钟状态的结果——当 NTP 完成校正后，currentTimeMillis() 的值会立刻变化，但这个变化不是它的问题，而是系统时钟被改写了。
误差本质：它不“同步”，只“读取”
currentTimeMillis() 是一个纯读取接口，没有网络通信、不调用 NTP、也不做任何校准。它的返回值完全取决于操作系统内核维护的实时时钟（CLOCK_REALTIME）。NTP 客户端（如 chronyd 或 ntpd）在后台运行，定期与时间服务器交互，最终通过系统调用（如 clock_settime）修改内核时钟。一旦修改完成，currentTimeMillis() 下一次调用就会返回新值。
- 如果 NTP 做的是平滑校正（slew），时钟缓慢调整 → currentTimeMillis() 变化平缓，误差逐步收敛；
- 如果 NTP 做的是跳跃校正（step），比如偏移超过 128ms 时触发 → currentTimeMillis() 可能突降或突增，出现明显跳变甚至负数差值；
- Android 设备还可能叠加 NITZ（网络标识和时区）信号带来的额外修正，进一步增加不确定性。
典型误差表现及原因
你在代码中观察到的“误差”，往往对应以下几种真实场景：
- 测量为 0 或负数：两次调用间隔短于系统时钟粒度（Windows 约 15ms，Linux 通常 1–10ms），导致返回相同值；或 NTP 回拨后 end
- 单次偏差达几十毫秒：容器环境、云主机虚拟时钟漂移、JVM 启动瞬间未完成 NTP 同步；
- 跨设备时间不可比：两台机器各自调用 currentTimeMillis()，结果差异包含各自时钟漂移 + 网络延迟，不能直接相减得出传输耗时。
怎么应对？关键不在“修”它，而在“换用”
你不该试图让 currentTimeMillis() 更准，而应明确它的用途边界：
- ✅ 适合：日志时间戳、数据库 created_at 字段、业务语义时间（如“今天下单”）；
- ❌ 不适合：超时控制、耗时统计、缓存过期判断、分布式序列生成——这些必须用 System.nanoTime()；
- ? 若需评估本地时钟偏移（即“慢了多少”），必须主动对接可信时间源（如 NTP 服务或 HTTP 时间 API），靠多次采样+滤噪估算，不能仅靠 currentTimeMillis() 自己算。
生产建议：监控 + 隔离 + 替代
真正健壮的时间处理，是组合策略：
- 启动时记录 currentTimeMillis()，之后定期比对，发现倒退立即告警；
- 所有定时、超时、间隔逻辑统一基于 nanoTime() 实现；
- 对外暴露时间戳时，可封装一层“可信时间提供者”，内部自动 fallback 到 NTP 客户端或可信 HTTP 接口；
- 在 Kubernetes 或 VM 环境中，确保宿主机已启用 chronyd slewing 模式（-s 参数），避免 step 跳跃。
