system.currenttimemillis()精度极限为1–15ms，取决于操作系统和硬件，不单调、受ntp校时影响，仅适用于秒级粗略计时，测短耗时应选system.nanotime()或jmh。

System.currentTimeMillis() 的精度极限不是由 Java 自身决定的，而是取决于底层操作系统时钟的更新频率和硬件支持能力。它无法突破系统级时钟分辨率的物理限制。

实际精度通常为 1–15 毫秒

不同系统表现不同：

• Windows 系统：普遍为 10–16ms（受 GetSystemTimeAsFileTime 和系统定时器中断间隔影响）
• Linux 系统：一般可达 1–10ms，取决于内核配置（如 HZ 值）和是否启用高精度时钟（CLOCK_MONOTONIC 或 CLOCK_REALTIME）
• 容器或虚拟机环境：可能进一步劣化，因时钟虚拟化引入额外延迟

同一毫秒内多次调用返回相同值

这是精度极限最直接的表现：

左手医生开放平台

左手医生开放平台是一款面向智慧医疗服务建设的 AI 医疗开放平台。

下载

• 若两次调用间隔小于系统时钟最小更新粒度，返回值完全一致
• 高并发场景下（如批量请求、ID 生成），大量线程在同一毫秒内获取到相同时间戳，导致“时间退化”
• 例如：1000 个请求在 3ms 内到达，可能只有 1–2 个不同毫秒值，其余全重复

精度不等于稳定性，时钟跳变会破坏连续性

即使数值看起来“递增”，也不代表真实流逝时间：

• NTP 同步可能导致时间回拨（currentTimeMillis() 突然变小）或快进
• 管理员手动修改系统时间会直接改变返回值，造成负耗时、日志倒序等异常
• 它不保证单调性——这点与 System.nanoTime() 有本质区别

它适合什么，不适合什么

关键看用途是否容忍毫秒级模糊和跳变：

• ✅ 适合：日志打点（毫秒足够可读）、缓存过期判断（±10ms 误差无影响）、简单超时控制（如 30 秒级 timeout）
• ❌ 不适合：纳秒级性能微基准测试、分布式唯一 ID 的主时间源、强顺序事件排序、实时音视频同步等对单调性或亚毫秒精度敏感的场景