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） - 容器或虚拟机环境：可能进一步劣化，因时钟虚拟化引入额外延迟
同一毫秒内多次调用返回相同值
这是精度极限最直接的表现：
- 若两次调用间隔小于系统时钟最小更新粒度，返回值完全一致
- 高并发场景下（如批量请求、ID 生成），大量线程在同一毫秒内获取到相同时间戳，导致“时间退化”
- 例如：1000 个请求在 3ms 内到达，可能只有 1–2 个不同毫秒值，其余全重复
精度不等于稳定性，时钟跳变会破坏连续性
即使数值看起来“递增”，也不代表真实流逝时间：
- NTP 同步可能导致时间回拨（
currentTimeMillis()突然变小）或快进 - 管理员手动修改系统时间会直接改变返回值，造成负耗时、日志倒序等异常
- 它不保证单调性——这点与
System.nanoTime()有本质区别
它适合什么，不适合什么
关键看用途是否容忍毫秒级模糊和跳变：
- ✅ 适合：日志打点（毫秒足够可读）、缓存过期判断（±10ms 误差无影响）、简单超时控制（如 30 秒级 timeout）
- ❌ 不适合：纳秒级性能微基准测试、分布式唯一 ID 的主时间源、强顺序事件排序、实时音视频同步等对单调性或亚毫秒精度敏感的场景
