System.currentTimeMillis()返回自1970-01-01 00:00:00 UTC起的毫秒数，是无时区信息的Unix时间戳，非日历时间；它轻量高效但易因时区、分布式时钟漂移引发错误。
System.currentTimeMillis() 返回什么，为什么它不是“当前时间”
System.currentTimeMillis() 返回的是从 1970-01-01 00:00:00 UTC 到现在的毫秒数，本质是 Unix 时间戳（毫秒级）。但它不带时区信息，也不代表某个具体时刻的“日历时间”——只是个数字。很多人误以为它能直接用于格式化或跨时区计算，结果发现显示时间错 8 小时（比如在中国用 SimpleDateFormat 默认用本地时区解析，但输入却当成 UTC 处理）。
常见错误现象：
• 用 new Date(System.currentTimeMillis()) 再转成字符串，结果在不同时区服务器上输出不同
• 把它当 Instant 直接传给 LocalDateTime.ofInstant() 却忘了转换时区
• 存进数据库时没注明是 UTC，导致查询时时间漂移
- 它返回
long，不是对象，零开销，适合性能敏感场景（如埋点打点、超时判断） - 它依赖系统时钟，若系统时间被手动调整或 NTP 同步跳变，值可能回退或突增（
Instant.now()同样受此影响，但语义更清晰） - 不能直接参与日期运算（比如“加 3 天”），必须先转成
Instant或LocalDateTime
Instant.now() 和 System.currentTimeMillis() 怎么互转才安全
两者数值等价，但类型和语义不同：System.currentTimeMillis() 是原始时间戳；Instant.now() 是不可变的时间点对象，自带纳秒精度（虽然系统时钟通常只到毫秒）。互转本身很简单，但容易忽略精度截断和时区隐含假设。
正确做法：
- 从
Instant→ 毫秒：用instant.toEpochMilli()，这是标准方式，不会丢失精度（纳秒部分被舍去） - 从毫秒 →
Instant：用Instant.ofEpochMilli(millis)，别用new Date(millis).toInstant()—— 多余构造且易混淆 - 避免用
Instant.ofEpochSecond(millis / 1000)，会丢毫秒，除非你明确只要秒级
示例：
long ts = System.currentTimeMillis();<br>Instant instant = Instant.ofEpochMilli(ts); // ✅ 安全<br>long back = instant.toEpochMilli(); // ✅ 一定等于 ts
什么时候该用 Instant，什么时候坚持用 long 毫秒
选型关键不在“新旧”，而在“用途”。Java 8 的时间 API 不是为了取代 System.currentTimeMillis()，而是补足它缺失的语义。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 做定时器、超时控制、缓存过期（如
if (System.currentTimeMillis() - start > 5000)）→ 用long，轻量、无对象创建开销 - 要记录事件发生时刻并后续做时区转换（如“用户下单时间转成东京时间显示”）→ 必须用
Instant，它是时区中立的基准点 - 和数据库交互：JDBC 4.2+ 支持
Instant直接 set/get，比java.sql.Timestamp更干净；但如果 ORM（如 MyBatis）没配好类型处理器，反而容易映射失败，此时退回到long更稳
性能提示：在高频循环里每轮都调 Instant.now()，比 System.currentTimeMillis() 略慢（多一次对象分配+纳秒处理），但差异通常在纳秒级，除非压测到百万 QPS 级别，否则不用纠结。
System.currentTimeMillis() 在分布式环境下的坑
单机没问题，一上集群就暴露本质：它只反映本机系统时钟。NTP 同步有误差，虚拟机可能暂停，容器可能漂移——导致两台机器的 System.currentTimeMillis() 差几十毫秒甚至更多。这不是 bug，是设计使然。
典型问题场景：
- 用它生成订单号前缀，结果在 A 机和 B 机同时生成相同时间戳，靠后缀自增又没全局协调 → ID 冲突
- 基于它实现简单分布式锁（比如“锁过期时间 = now + 30s”），但各节点对 “now” 理解不一致 → 锁提前释放或死锁
- 日志时间戳看起来乱序，排查链路时误判执行顺序
缓解方法：
• 关键业务不要单独依赖它，至少叠加机器 ID 或序列号（如 Snowflake）
• 分布式追踪用 Instant.now().toEpochMilli() 没帮助，得上 Tracer.currentSpan().context().traceId() 这类专用机制
• 监控系统时间偏移（如 ntpdate -q pool.ntp.org），告警偏差 > 50ms 的节点
真正需要强一致时间戳的场景，得换方案：Log Sequence Number、Hybrid Logical Clock，或者直接上 TSO（Timestamp Oracle）服务。这时候 System.currentTimeMillis() 连入场券都不算。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
