golang 定时任务方面time.Sleep和time.Tick的优劣对比
定时任务实现方式
golang 写循环执行的定时任务,常见的有以下三种实现方式:
time.Sleep方法
1
2
3
4
for {
time.Sleep(time.Second)
fmt.Println("我在定时执行任务")
}
time.Tick函数
t1:=time.Tick(3*time.Second)
for {
select {
case <-t1:
fmt.Println("t1定时器")
}
}
time.NewTicker
其中 Tick
定时任务,也可以先使用 time.Ticker
函数获取 Ticker
结构体,然后进行阻塞监听信息,这种方式可以手动选择停止定时任务,在停止任务时,减少对内存的浪费。
1
2
3
4
5
6
7
8
9
t:=time.NewTicker(time.Second)
for {
select {
case <-t.C:
fmt.Println("t1定时器")
t.Stop()
}
}
其中第二种和第三种可以归为同一类
三种定时器的实现原理
一般来说,你在使用执行定时任务的时候,一般旁人会劝你不要使用 time.Sleep
完成定时任务,但是为什么不能使用 Sleep
函数完成定时任务呢,它和 Tick
函数比,有什么劣势呢?这就需要我们去探讨阅读一下源码,分析一下它们之间的优劣性。
time.Tick
首先,我们研究一下 Tick
函数
1
func Tick(d Duration) <-chan Time
调用 Tick
函数会返回一个时间类型的 channel
,如果对 channel
稍微有些了解的话,我们首先会想到,既然是返回一个 channel
,在调用 Tick
方法的过程中,必然创建了 goroutine
,该 Goroutine
负责发送数据,唤醒被阻塞的定时任务。我在阅读源码之后,确实发现函数中go出去了一个协程,处理定时任务。
按照当前的理解,使用一个 tick
,需要go出去一个协程,效率和对内存空间的占用肯定不能比 sleep
函数强。我们需要继续阅读源码才拿获取到真理。
简单的调用过程我就不陈述了,我在这介绍一下核心结构体和方法(删除了部分判断代码,解释我写在表格中):
1
2
3
4
5
6
7
8
9
10
11
func (tb *timersBucket) addtimerLocked(t *timer) {
t.i = len(tb.t) //计算timersBucket中,当前定时任务的长度
tb.t = append(tb.t, t)// 将当前定时任务加入timersBucket
siftupTimer(tb.t, t.i) //维护一个timer结构体的最小堆(四叉树),排序关键字为执行时间,即该定时任务下一次执行的时间
if !tb.created {
tb.created = true
go timerproc(tb)// 如果还没有创建过管理定时任务的协程,则创建一个,执行通知管理timer的协程,最核心代码
}
}
timersBucket
,顾名思义,时间任务桶,是外界不可见的全局变量。每当有新的 timer
定时器任务时,会将 timer
加入到 timersBucket
中的 timer
切片。 timerBucket
结构体如下:
1
2
3
4
type timersBucket struct {
lock mutex //添加新定时任务时需要加锁(冲突点在于维护堆)
t []*timer //timer切片,构造方式为四叉树最小堆
}
func timerproc(tb *timersBucket) 详细介绍
可以称之为定时任务处理器,所有的定时任务都会加入 timersBucket
,然后在该函数中等待被处理。等待被处理的 timer
,根据 when
字段(任务执行的时间,int类型,纳秒级别)构成一个最小堆,每次处理完成堆顶的某个 timer
时,会给它的 when
字段加上定时任务循环间隔时间(即Tick(d Duration) 中的 d
参数),然后重新维护堆,保证 when
最小的 timer
在堆顶。当堆中没有可以处理的 timer
(有timer
,但是还不到执行时间),需要计算当前时间和堆顶中 timer
的任务执行时间差值 delta
,定时任务处理器沉睡 delta
段时间,等待被调度器唤醒。核心代码如下(注释写在每行代码的后面,删除一些判断代码以及不利于阅读的非核心代码):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
func timerproc(tb *timersBucket) {
for {
lock(&tb.lock) //加锁
now := nanotime() //当前时间的纳秒值
delta := int64(-1) //最近要执行的timer和当前时间的差值
for {
if len(tb.t) == 0 {
delta = -1
break
}//当前无可执行timer,直接跳出该循环
t := tb.t[0]
delta = t.when - now //取when组小的的timer,计算于当前时间的差值
if delta > 0 {
break
}// delta大于0,说明还未到发送channel时间,需要跳出循环去睡眠delta时间
if t.period > 0 {
// leave in heap but adjust next time to fire
t.when += t.period * (1 + -delta/t.period)// 计算该timer下次执行任务的时间
siftdownTimer(tb.t, 0) //调整堆
} else {
// remove from heap,如果没有设定下次执行时间,则将该timer从堆中移除(time.after和time.sleep函数即是只执行一次定时任务)
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)//解锁
f(arg, seq) //在channel中发送time结构体,唤醒阻塞的协程
lock(&tb.lock)
}
if delta < 0 {
// No timers left - put goroutine to sleep.
goparkunlock(&tb.lock, "timer goroutine (idle)", traceEvGoBlock, 1)
continue
}// delta小于0说明当前无定时任务,直接进行阻塞进行睡眠
tb.sleeping = true
tb.sleepUntil = now + delta
unlock(&tb.lock)
notetsleepg(&tb.waitnote, delta) //睡眠delta时间,唤醒之后就可以执行在堆顶的定时任务了
}
}
至此, time.Tick
函数涉及到的主要功能就讲解结束了,总结一下就是启动定时任务时,会创建一个唯一协程,处理 timer
,所以的 timer
都在该协程中处理。
然后,我们再阅读一下 sleep
的源码实现,核心源码如下:
1
2
3
4
5
6
7
8
9
10
11
//go:linkname timeSleep time.Sleep
func timeSleep(ns int64) {
*t = timer{} //创建一个定时任务
t.when = nanotime() + ns //计算定时任务的执行时间点
t.f = goroutineReady //执行方法
tb.addtimerLocked(t) //加入timer堆,并在timer定时任务执行协程中等待被执行
goparkunlock(&tb.lock, "sleep", traceEvGoSleep, 2) //睡眠,等待定时任务协程通知唤醒
}
读了 sleep
的核心代码之后,是不是突然发现和 Tick
函数的内容很类似,都创建了 timer
,并加入了定时任务处理协程。神奇之处就在于,实际上这两个函数产生的 timer
都放入了同一个 timer
堆,都在定时任务处理协程中等待被处理。
优劣性对比,使用建议
现在我们知道了,Tick
,Sleep
,包括 time.After
函数,都使用的 timer
结构体,都会被放在同一个协程中统一处理,这样看起来使用 Tick
, Sleep
并没有什么区别。
实际上是有区别的, Sleep
是使用睡眠完成定时任务,需要被调度唤醒。 Tick
函数是使用 channel
阻塞当前协程,完成定时任务的执行。当前并不清楚golang 阻塞和睡眠对资源的消耗会有什么区别,这方面不能给出建议。
但是使用 channel
阻塞协程完成定时任务比较灵活,可以结合 select
设置超时时间以及默认执行方法,而且可以设置 timer
的主动关闭,以及不需要每次都生成一个 timer
(这方面节省系统内存,垃圾收回也需要时间)。
所以,建议使用 time.Tick
完成定时任务。