System.currentTimeMillis() 无法抵御回拨，因其直接映射系统实时时钟，而NTP跳跃校正会使其突降；应改用System.nanoTime()等单调时钟做超时、间隔计算，挂钟时间仅用于显示或业务语义。
Java 中的 System.currentTimeMillis() 返回的是自 Unix 纪元（1970-01-01 00:00:00 UTC）以来的毫秒数，它依赖于系统时钟。当 NTP 同步导致系统时钟**向后调整（回拨）**时，currentTimeMillis() 可能会突然变小，造成时间“倒流”。这对依赖单调递增时间戳的逻辑（如超时控制、缓存过期、分布式序列生成）非常危险。
为什么 currentTimeMillis 无法抵御回拨
currentTimeMillis() 是对操作系统 gettimeofday()（Linux）或 GetSystemTimeAsFileTime()（Windows）等系统调用的封装，其值直接反映系统实时时钟。NTP 客户端（如 ntpd 或 chronyd）在检测到本地时钟偏移较大时，可能选择**跳跃式校正（step adjustment）**——直接写入新时间，而非缓慢 slewing。此时 currentTimeMillis() 就会跳变，不保证单调性。
应对回拨的核心思路：改用单调时钟
真正可靠的方式是**不依赖实时时钟做顺序/差值判断**，而是使用操作系统提供的、不受 NTP 调整影响的**单调时钟（monotonic clock）**：
- Java 9+ 提供了
System.nanoTime()：返回自某个未指定起点起的纳秒数，保证严格单调递增，且不受系统时钟调整影响。适合测时长、计算间隔、实现超时等待。 - 若需带语义的时间戳（如日志打点、数据库记录），应将
currentTimeMillis()视为“挂钟时间”，仅用于显示或业务含义；而所有逻辑判断（如“是否超时 5 秒”）必须基于nanoTime()的差值。
典型场景改造示例
比如一个简单的超时等待逻辑：
// ❌ 危险：受回拨影响
long start = System.currentTimeMillis();
while (System.currentTimeMillis() - start < 5000) {
// 等待最多 5 秒
}应改为：
// ✅ 安全：基于单调时钟
long startNanos = System.nanoTime();
long timeoutNanos = 5_000_000_000L; // 5 秒 = 50 亿纳秒
while (System.nanoTime() - startNanos < timeoutNanos) {
// 等待最多 5 秒
}注意：nanoTime() 不代表真实时间，不能用于计算“几点几分”，但完美胜任“过了多久”这类需求。
补充建议：监控与兜底
即便使用 nanoTime()，仍建议对系统时钟健康度保持关注：
- 部署时启用 NTP 的 slewing 模式（如
chronyd -s或ntpd -x），避免大步跳跃； - 在关键服务启动时记录
currentTimeMillis()，定期采样比对，若发现明显倒退（如连续两次采样差值为负且绝对值 >100ms），可触发告警； - 对极少数必须依赖挂钟单调性的场景（如全局唯一有序 ID），考虑引入逻辑时钟（如 Lamport timestamp）或混合逻辑时钟（HLC）方案，而非硬扛系统时钟。
