1. 情景描述：
线上某系统大约运行了半个多月的时间，突然发现系统的交易处理时间延迟从最初的70ms 变成7s，也就是系统性能下降了100倍左右。经过一番盘查发现top命令下的系统CPU占用率几乎达到99.9%，然后重启系统之后问题未重现，第二天top一下CPU 20%, 第三天CPU占用率到30%，而且还有上升趋势。
从上面的情景描述看，显然是系统中某种消耗CPU资源的任务发生了泄露。通过pprof最终定位到系统的timer调度占用几乎所有的CPU时间。这引起了笔者的极大兴趣，于是笔者通过google神奇进行golang cpu timer相关的搜索。随后golang语言Api系统中CPU功耗优化300倍的过程这篇文章的博主给了笔者很大启发，应该是程序中某些地方的Tick的使用姿势不对，于是笔者开始了对time.After和time.Tick背后原理的追溯。
2. 定时器的使用
golang的定时器的使用非常简单，一般我们用的比较多的就是Timer和Ticker，如下所示：
//场景1：for { select { case <- time.After(10 * time.Microsecond):
fmt.Println("hello timer")
}
}//场景2：for { select { case <- time.Tick(10 * time.Microsecond):
fmt.Println("hello, tick")
}
}乍一看这两种调用方式都没有问题，而且短时间测试两种方式的效果看起来一样，然后如果测试时你使用top命令查看两种场景下的进程CPU占用率，你会大吃一惊，截图如下：
场景1-time_after
场景2-time_tick
从上面两图中可以看出After的用法比同用法下的Tick的CPU占用率小很多，而且tick的CPU占用率是很快就上升到100%的，如果这里的间隔时间设置稍微大一些可以更加明显的观察到Tick进程的CPU占用率上升的情况，那这是什么原因呢？
3.定时器的实现原理
记得哪里看过一句话，源码面前，了无秘密。我们还是顺着Tick和After方法的源码探寻事情的真相吧.
After的相关源码
//1.After方法， 创建了一个Timer对象并返回其chanelfunc After(d Duration) <-chan Time { return NewTimer(d).C
}//2.NewTimer方法， 创建一个Timer对象并启动之，这里when方法是辅助定时时间的，sendTime用于向通道中返回Time对象，然后启动定时器func NewTimer(d Duration) *Timer {
c := make(chan Time, 1)
t := &Timer{
C: c,
r: runtimeTimer{
when: when(d),
f: sendTime,
arg: c,
},
}
startTimer(&t.r) return t
}Tick的相关源码
//1.创建Ticker对象，这里定时时间不允许小于0，否则可能会发生panicfunc Tick(d Duration) <-chan Time { if d <= 0 { return nil
} return NewTicker(d).C
}//2.从NewTicker的源码来看，Ticker的基本数据结构和Timer类似，不同的是这里new的runtimeTimer加上了一个period的变量。func NewTicker(d Duration) *Ticker { if d <= 0 {
panic(errors.New("non-positive interval for NewTicker"))
} // Give the channel a 1-element time buffer.
// If the client falls behind while reading, we drop ticks
// on the floor until the client catches up.
c := make(chan Time, 1)
t := &Ticker{
C: c,
r: runtimeTimer{
when: when(d),
period: int64(d),
f: sendTime,
arg: c,
},
}
startTimer(&t.r) return t
}从Timer和Ticker的源码中可以看出，其启动都是通过startTimer进行启动的，startTimer的实现在runtime/time.go中。
//1.startTimer将new的timer对象加入timer的堆数据结构中//startTimer adds t to the timer heap.//go:linkname startTimer time.startTimerfunc startTimer(t *timer) { if raceenabled {
racerelease(unsafe.Pointer(t))
}
addtimer(t)
}func addtimer(t *timer) {
tb := t.assignBucket()
lock(&tb.lock)
tb.addtimerLocked(t)
unlock(&tb.lock)
}// Add a timer to the heap and start or kick timerproc if the new timer is// earlier than any of the others.// Timers are locked.func (tb *timersBucket) addtimerLocked(t *timer) { // when must never be negative; otherwise timerproc will overflow
// during its delta calculation and never expire other runtime timers.
if t.when < 0 {
t.when = 1<<63 - 1
}
t.i = len(tb.t)
tb.t = append(tb.t, t)
siftupTimer(tb.t, t.i) if t.i == 0 { // siftup moved to top: new earliest deadline.
if tb.sleeping {
tb.sleeping = false
notewakeup(&tb.waitnote)
} if tb.rescheduling {
tb.rescheduling = false
goready(tb.gp, 0)
}
} if !tb.created {
tb.created = true
go timerproc(tb)
}
}type timersBucket struct {
lock mutex
gp *g
created bool
sleeping bool
rescheduling bool
sleepUntil int64
waitnote note
t []*timer
}定时器处理逻辑
func timerproc(tb *timersBucket) {
tb.gp = getg() for {
lock(&tb.lock)
tb.sleeping = false
now := nanotime()
delta := int64(-1) for { if len(tb.t) == 0 { //无timer的情况
delta = -1
break
}
t := tb.t[0] //拿到堆顶的timer
delta = t.when - now if delta > 0 { // 所有timer的时间都没有到期
break
} if t.period > 0 { // t[0] 是ticker类型，调整其到期时间并调整timer堆结构
// leave in heap but adjust next time to fire
t.when += t.period * (1 + -delta/t.period)
siftdownTimer(tb.t, 0)
} else { //Timer类型的定时器是单次的，所以这里需要将其从堆里面删除
// remove from heap
last := len(tb.t) - 1
if last > 0 {
tb.t[0] = tb.t[last]
tb.t[0].i = 0
}
tb.t[last] = nil
tb.t = tb.t[:last] if last > 0 {
siftdownTimer(tb.t, 0)
}
t.i = -1 // mark as removed
}
f := t.f
arg := t.arg
seq := t.seq unlock(&tb.lock)
if raceenabled {
raceacquire(unsafe.Pointer(t))
}
f(arg, seq) //调用定时器处理函数
lock(&tb.lock)
} if delta < 0 || faketime > 0 { // No timers left - put goroutine to sleep.
tb.rescheduling = true
goparkunlock(&tb.lock, "timer goroutine (idle)", traceEvGoBlock, 1)
continue
} // At least one timer pending. Sleep until then.
tb.sleeping = true
tb.sleepUntil = now + delta noteclear(&tb.waitnote)
unlock(&tb.lock)
notetsleepg(&tb.waitnote, delta)
}
}以上便是定时器调用的主要逻辑，这里总结一下基本原理：
所有timer统一使用一个最小堆结构去维护，按照timer的when（到期时间）比较大小；
timer处理线程从堆顶开始处理每个timer, 对于到期的timer, 如果其period>0, 则表明该timer 属于Ticker类型，调整其下次到期时间并调整其在堆中的位置，否则从堆中移除该timer;
调用该timer的处理函数以及其他相关工作；
4. 再论定时器的正确使用姿势
从第3节的源码中我们可以看到After和Tick其实是一个创建了一个单次的timer一个是创建了一个永久性的timer。因此场景2中Tick的用法会导致进程中创建无数个Tick，这最终导致了timer处理线程忙死。因此，使用Tick进行定时任务的话我们可以将Tick对象建在循环外面：
tick := time.Tick(10 * time.Microsecond) for {
select { case <- tick:
fmt.Printf("hello, tick 2")
}
}其次golang的处理方式中也可以看出，go的timer的处理和用户端程序定义的间隔时间不一定完全精准，用户的回调函数执行时间越长单个timer对堆中其他邻近timer的影响越大。因此timer的回调函数一定是执行时间越短越好。
作者：Alburt
链接：https://www.jianshu.com/p/c9e8aaa13415