Go 語言定時任務 time-Sleep 和 time-Tick 的優劣對比分析
golang 寫循環執行的定時任務，常見的有以下三種實現方式
1、time.Sleep 方法：
for {
time.Sleep(time.Second)
fmt.Println("我在定時執行任務")
}2、time.Tick 函數：
t1:=time.Tick(3*time.Second)
for {
select {
case <-t1:
fmt.Println("t1定時器")
}
}3、其中 Tick 定時任務
也可以先使用time.Ticker函數獲取Ticker結構體，然後進行阻塞監聽信息，這種方式可以手動選擇停止定時任務，在停止任務時，減少對內存的浪費。
t:=time.NewTicker(time.Second)
for {
select {
case <-t.C:
fmt.Println("t1定時器")
t.Stop()
}
}其中第二種和第三種可以歸爲同一類
這三種定時器的實現原理
一般來說，你在使用執行定時任務的時候，一般旁人會勸你不要使用time.Sleep完成定時任務，但是爲什麼不能使用Sleep函數完成定時任務呢，它和Tick函數比，有什麼劣勢呢？
這就需要我們去探討閱讀一下源碼，分析一下它們之間的優劣性。
首先，我們研究一下Tick函數，func Tick(d Duration) <-chan Time
調用Tick函數會返回一個時間類型的channel，如果對channel稍微有些瞭解的話，我們首先會想到，既然是返回一個channel，在調用Tick方法的過程中，必然創建了goroutine, 該Goroutine負責發送數據，喚醒被阻塞的定時任務。
我在閱讀源碼之後，確實發現函數中 go 出去了一個協程，處理定時任務。
按照當前的理解，使用一個tick, 需要 go 出去一個協程，效率和對內存空間的佔用肯定不能比sleep函數強。我們需要繼續閱讀源碼纔拿獲取到真理。
簡單的調用過程我就不陳述了，我在這介紹一下核心結構體和方法（刪除了部分判斷代碼，解釋我寫在表格中）：
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結構體如下：
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段時間，等待被調度器喚醒。
核心代碼如下（註釋寫在每行代碼的後面，刪除一些判斷代碼以及不利於閱讀的非核心代碼）：
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 的源碼實現，核心源碼如下：
//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完成定時任務。
參考鏈接：https://www.jb51.net/article/211330.htm
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gj99eoF1NZz2a8DpcRvV-A