system.currenttimemillis()开销极小，通常10–50纳秒，远低于内存读取或方法调用成本；日常开发无需担心性能，仅在每微秒调用、tight loop百万次或实时嵌入式场景才需优化。
System.currentTimeMillis() 的开销极小，通常在纳秒级，远低于一次内存读取或方法调用的平均成本，日常开发中完全无需担心性能问题。
底层实现非常轻量
在主流 JVM（如 HotSpot）中，System.currentTimeMillis() 并非每次调用都触发系统调用。JVM 会缓存上一次获取的时间，并结合高精度计时器（如 clock_gettime(CLOCK_MONOTONIC) 或平台等效机制）做增量修正。实际耗时通常为 10–50 纳秒，比一次普通对象字段访问还快。
和其它时间获取方式对比明显
- System.nanoTime()：开销相近甚至略低（纯单调时钟，无时区/闰秒处理），但返回的是相对时间，不能直接表示“当前时刻”；
- new Date().getTime()：涉及对象分配 + 构造函数调用，至少多出 100+ 纳秒，还有 GC 压力；
- Instant.now().toEpochMilli()（Java 8+）：创建 Instant 对象 + 内部转换，开销约为 currentTimeMillis() 的 3–5 倍；
- 日志框架自动打时间戳（如 Logback 的 %d）：多数已优化为线程本地缓存或预计算，实际不额外调用 currentTimeMillis。
什么情况下才真要留意？
仅在以下极端场景中，调用频率本身才可能成为瓶颈（而非单次开销）：
- 每微秒都要记录一个时间戳（例如高频量化交易 tick 处理循环）；
- 在 tight loop 中每轮都调用（如百万次空循环里反复取时间）；
- 嵌入式或实时性要求极高的环境（JVM 未优化或使用非标准实现）。
此时可考虑：单次取值复用、使用 nanoTime 做差值、或借助环形缓冲区批量打点。
总结建议
- 日常业务逻辑、日志、监控埋点，放心用 System.currentTimeMillis()；
- 避免在 hot path 中重复调用多次——不是因为慢，而是语义冗余；
- 需要高精度间隔测量优先选 System.nanoTime()；
- 需要可读时间或时区支持，再考虑 Instant 或 LocalDateTime，但别在性能敏感路径频繁构建它们。
