在Go协程中测量时间：高频调用time.Now()的Linux性能成本探究

Hey folks，这个问题问得相当到位——普通场景下用time.Now()做计时确实没压力，但一旦走到每秒并行5000次以上的高频场景，尤其是在Linux系统下，它的开销就真的得拎出来说道说道了。

先给新手打个底：普通场景完全不用慌 #

咱日常开发里给单个函数计时，就用最常规的写法就行，开销可以忽略到完全感知不到：

start := time.Now()
// 执行你的业务逻辑
cost := time.Since(start)
fmt.Printf("函数耗时：%v\n", cost)

这种单次/低频次调用，time.Now()的系统调用开销根本不会成为性能瓶颈。

高频场景的核心问题：Linux下的系统调用开销 #

当你把调用频次拉到5000次/秒甚至更高时，问题就来了：Linux系统下time.Now()默认依赖CLOCK_REALTIME时钟，每次调用都会触发一次用户态到内核态的切换（系统调用）。这种切换单次看几十纳秒不多，但架不住量，并行场景下还会带来上下文切换的额外开销，累积起来就会吃掉不少CPU资源。

优化方案（基于业内验证的靠谱实践） #

针对这种高频计时需求，有几个经过验证的优化方向：

• 优先用单调时钟计时：Go 1.9之后的time.Now()已经内置了单调时钟，而time.Since(start)会自动优先使用单调时钟来计算耗时——不仅能避免系统时间调整（比如NTP同步）带来的计时误差，还能减少额外的系统调用开销
• 时间缓存批量复用：如果你的计时不需要精确到纳秒级，可以每隔固定周期（比如1毫秒）缓存一次当前时间，用缓存值来计算多个操作的耗时，直接把系统调用次数砍到原来的千分之一甚至更低
• 直接调用高精度内核时钟：如果追求极致性能，可以通过syscall或cgo直接调用Linux的clock_gettime(CLOCK_MONOTONIC_RAW)——这个时钟不会受到NTP调整的影响，且系统调用开销比CLOCK_REALTIME略低

实测数据参考（Linux x86_64环境） #

在普通的云服务器上，单次time.Now()调用的开销大概在30-80纳秒之间。当你每秒调用5000次时，总开销大概在0.15-0.4ms；如果是并行调用，这个开销会因为上下文切换放大到0.5-1ms左右，对于CPU密集型的高性能服务来说，这部分开销已经是不可忽视的了。

内容的提问来源于stack exchange，提问作者Prune