time.Ticker 的性能

Question

无法找出在下面的 for 循环中我们花费超过 10 微秒的位置，以至于我们错过了大量的滴答声？

package main

import (
    "context"
    "fmt"
    "time"
)

func main() {
    RunTicker(time.Millisecond, 10 * time.Second) // Scenario 1
    RunTicker(10 * time.Microsecond, 10 * time.Second) // Scenario 2
}

func RunTicker(tickerInterval, tickerDuration time.Duration) {
    var counter int

    ctx, can := context.WithTimeout(context.Background(), tickerDuration)
    defer can()

    ticker := time.NewTicker(tickerInterval)

exitfor:
    for {
        select {
        case <-ticker.C:
            counter++
        case <- ctx.Done():
            ticker.Stop()
            break exitfor
        }
    }

    fmt.Printf("Tick interval %v and running for %v.Expected counter: %d but got %d\n", tickerInterval, tickerDuration, tickerDuration/tickerInterval, counter)
}

输出:

Tick interval 1ms and running for 10s.Expected counter: 10000 but got 9965
Tick interval 10µs and running for 10s.Expected counter: 1000000 but got 976590

Answer 1

一般来说，当一个 API 说一个事件将花费 X 秒时，它实际上保证耗时将至少 X 秒，而不是更少。特别是对于小的时间增量，这是一个重要的区别。

此外，考虑来自 NewTicker documentation 的这一点:

The period of the ticks is specified by the duration argument. The ticker will adjust the time interval or drop ticks to make up for slow receivers.

考虑到这两点，您真正拥有的唯一保证是实际报价的数量 <= 您计算的预期数量，仅此而已。换句话说，只有在理想情况中，实际报价 == 预期报价，而其他所有情况都将小于此值。

在这些小时间增量(~< 1 毫秒)中，除了“用户代码”之外，可能还有其他事件超过滴答时间，包括:

• Goroutine 调度逻辑(休眠和恢复 goroutine、线程切换)。
• 垃圾收集(即使在循环中没有产生垃圾，GC 可能仍然“活跃”并且偶尔会检查垃圾)

这些其他因素可能同时发生，使得跳动被跳过或延迟的可能性更大。

把它想象成你有一个装满水的桶，你需要把它倒进另一个桶，然后再倒另一个桶，再倒一个，依此类推，持续 1000 个桶。 你唯一能做的就是失去水分，一旦溢出就无法再获得。在这种情况下，您绝不会期望将 100% 的水保留到最后。

这与您提到的情况类似，因为错误只朝一个方向。延迟只能至少达到指定的时间，并且只能丢失刻度(永远不会获得额外的)。每当这些事件发生时，就像失去了一滴水一样。