system.currenttimemillis() 返回自 unix 纪元以来的毫秒数，但不补偿 ntp 校时、手动调时或 vm 漂移等导致的时钟跳变，可能引发时间乱序；应优先用 system.nanotime() 测耗时，分布式场景需统一 ntp 或逻辑时钟。
System.currentTimeMillis() 返回的是自 Unix 纪元（1970-01-01 00:00:00 UTC）以来的毫秒数，底层依赖操作系统提供的系统时钟。它**不自动补偿时钟同步差异**（比如 NTP 调整、手动校时、虚拟机时钟漂移等），因此在分布式或高精度场景下，直接使用它可能引发时间乱序、逻辑错误或诊断困难。
理解时钟同步对 currentTimeMillis 的影响
操作系统时钟可能因以下原因发生跳变或漂移：
- NTP 客户端执行步进（step）校正：时间突然向前/向后跳几毫秒甚至几秒；
- VM 环境中宿主机时钟调整未及时同步到客户机（尤其在 suspend/resume 后）；
- 手动修改系统时间（如 root 执行 date 命令）；
- 硬件时钟缓慢漂移，NTP 仅做渐进式 slewing 补偿，但 currentTimeMillis 仍反映“墙钟”而非单调时钟。
这些都会导致 currentTimeMillis() 返回值非单调递增——即可能出现 t2
避免依赖绝对时间做顺序判断
不要用 currentTimeMillis() 的差值做严格时序断言（如 “if (t2 - t1 > 100) then…”），尤其在单次请求链路或事件排序中。例如：
long start = System.currentTimeMillis();<br>doWork();<br>long end = System.currentTimeMillis();<br>if (end - start > 5000) log.warn("Too slow!"); // 可能因时钟回拨误报
✅ 更稳妥替代：改用 System.nanoTime() 测量经过时间（它基于单调递增的高性能计时器，不受系统时钟调整影响）：
- 适用于耗时测量、超时控制、性能统计；
- 注意：nanoTime 不是 UTC 时间戳，不能转成日期，也不能跨 JVM 进程比较；
- 单位是纳秒，需除以 1_000_000L 转为毫秒（用于展示或兼容逻辑）。
分布式系统中需统一时间源
当多个 JVM 实例需要协同判断事件先后（如日志排序、分布式锁、因果一致性），仅靠各自 currentTimeMillis 不可靠。应：
- 确保所有节点启用 NTP（推荐使用 chrony 或 systemd-timesyncd），并配置合理 drift 阈值与同步频率；
- 在关键业务中引入逻辑时钟（如 Lamport timestamp）或混合逻辑时钟（HLC）；
- 对强时间敏感操作（如金融交易、审计日志），可接入外部授时服务（如 GPS/PTP 服务器），并用专用 SDK 获取高精度 UTC 时间戳；
- 记录日志时同时打上本地 timeMillis 和 NTP 校准状态（如 chronyc tracking 输出的 offset），便于事后排查时钟异常。
检测并缓解时钟异常
可在启动时和运行期主动监控系统时钟健康度：
- 启动时调用
chronyc tracking（Linux）或w32tm /query /status（Windows）检查 offset； - 定期采样 currentTimeMillis() 并与前值比较，若出现大幅倒退（如 >100ms）或突增（如 >1s），触发告警并标记后续时间戳为“不可信”；
- 使用 net.time4j 或 jsr310-ext 等库封装带校验的时间服务，自动过滤异常跳变；
- 在容器/K8s 环境中，避免挂载宿主机 /etc/localtime，改用 UTC 时区 + 显式 TZ=UTC，并确保 pause 容器与节点时钟同步策略一致。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
