golang 寫循環(huán)執(zhí)行的定時任務(wù),常見的有以下三種實現(xiàn)方式
1、time.Sleep方法:
for {
time.Sleep(time.Second)
fmt.Println("我在定時執(zhí)行任務(wù)")
}
2、time.Tick函數(shù):
t1:=time.Tick(3*time.Second)
for {
select {
case -t1:
fmt.Println("t1定時器")
}
}
3、其中Tick定時任務(wù)
也可以先使用time.Ticker函數(shù)獲取Ticker結(jié)構(gòu)體,然后進行阻塞監(jiān)聽信息,這種方式可以手動選擇停止定時任務(wù),在停止任務(wù)時,減少對內(nèi)存的浪費。
t:=time.NewTicker(time.Second)
for {
select {
case -t.C:
fmt.Println("t1定時器")
t.Stop()
}
}
其中第二種和第三種可以歸為同一類
這三種定時器的實現(xiàn)原理
一般來說,你在使用執(zhí)行定時任務(wù)的時候,一般旁人會勸你不要使用time.Sleep完成定時任務(wù),但是為什么不能使用Sleep函數(shù)完成定時任務(wù)呢,它和Tick函數(shù)比,有什么劣勢呢?這就需要我們?nèi)ヌ接戦喿x一下源碼,分析一下它們之間的優(yōu)劣性。
首先,我們研究一下Tick函數(shù),func Tick(d Duration) -chan Time
調(diào)用Tick函數(shù)會返回一個時間類型的channel,如果對channel稍微有些了解的話,我們首先會想到,既然是返回一個channel,在調(diào)用Tick方法的過程中,必然創(chuàng)建了goroutine,該Goroutine負(fù)責(zé)發(fā)送數(shù)據(jù),喚醒被阻塞的定時任務(wù)。我在閱讀源碼之后,確實發(fā)現(xiàn)函數(shù)中g(shù)o出去了一個協(xié)程,處理定時任務(wù)。
按照當(dāng)前的理解,使用一個tick,需要go出去一個協(xié)程,效率和對內(nèi)存空間的占用肯定不能比sleep函數(shù)強。我們需要繼續(xù)閱讀源碼才拿獲取到真理。
簡單的調(diào)用過程我就不陳述了,我在這介紹一下核心結(jié)構(gòu)體和方法(刪除了部分判斷代碼,解釋我寫在表格中):
func (tb *timersBucket) addtimerLocked(t *timer) {
t.i = len(tb.t) //計算timersBucket中,當(dāng)前定時任務(wù)的長度
tb.t = append(tb.t, t)// 將當(dāng)前定時任務(wù)加入timersBucket
siftupTimer(tb.t, t.i) //維護一個timer結(jié)構(gòu)體的最小堆(四叉樹),排序關(guān)鍵字為執(zhí)行時間,即該定時任務(wù)下一次執(zhí)行的時間
if !tb.created {
tb.created = true
go timerproc(tb)// 如果還沒有創(chuàng)建過管理定時任務(wù)的協(xié)程,則創(chuàng)建一個,執(zhí)行通知管理timer的協(xié)程,最核心代碼
}
}
timersBucket,顧名思義,時間任務(wù)桶,是外界不可見的全局變量。每當(dāng)有新的timer定時器任務(wù)時,會將timer加入到timersBucket中的timer切片。timerBucket結(jié)構(gòu)體如下:
type timersBucket struct {
lock mutex //添加新定時任務(wù)時需要加鎖(沖突點在于維護堆)
t []*timer //timer切片,構(gòu)造方式為四叉樹最小堆
}
func timerproc(tb *timersBucket) 詳細介紹
可以稱之為定時任務(wù)處理器,所有的定時任務(wù)都會加入timersBucket,然后在該函數(shù)中等待被處理。
等待被處理的timer,根據(jù)when字段(任務(wù)執(zhí)行的時間,int類型,納秒級別)構(gòu)成一個最小堆,每次處理完成堆頂?shù)哪硞€timer時,會給它的when字段加上定時任務(wù)循環(huán)間隔時間(即Tick(d Duration) 中的d參數(shù)),然后重新維護堆,保證when最小的timer在堆頂。當(dāng)堆中沒有可以處理的timer(有timer,但是還不到執(zhí)行時間),需要計算當(dāng)前時間和堆頂中timer的任務(wù)執(zhí)行時間差值delta,定時任務(wù)處理器沉睡delta段時間,等待被調(diào)度器喚醒。
核心代碼如下(注釋寫在每行代碼的后面,刪除一些判斷代碼以及不利于閱讀的非核心代碼):
func timerproc(tb *timersBucket) {
for {
lock(tb.lock) //加鎖
now := nanotime() //當(dāng)前時間的納秒值
delta := int64(-1) //最近要執(zhí)行的timer和當(dāng)前時間的差值
for {
if len(tb.t) == 0 {
delta = -1
break
}//當(dāng)前無可執(zhí)行timer,直接跳出該循環(huán)
t := tb.t[0]
delta = t.when - now //取when組小的的timer,計算于當(dāng)前時間的差值
if delta > 0 {
break
}// delta大于0,說明還未到發(fā)送channel時間,需要跳出循環(huán)去睡眠delta時間
if t.period > 0 {
// leave in heap but adjust next time to fire
t.when += t.period * (1 + -delta/t.period)// 計算該timer下次執(zhí)行任務(wù)的時間
siftdownTimer(tb.t, 0) //調(diào)整堆
} else {
// remove from heap,如果沒有設(shè)定下次執(zhí)行時間,則將該timer從堆中移除(time.after和time.sleep函數(shù)即是只執(zhí)行一次定時任務(wù))
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中發(fā)送time結(jié)構(gòu)體,喚醒阻塞的協(xié)程
lock(tb.lock)
}
if delta 0 {
// No timers left - put goroutine to sleep.
goparkunlock(tb.lock, "timer goroutine (idle)", traceEvGoBlock, 1)
continue
}// delta小于0說明當(dāng)前無定時任務(wù),直接進行阻塞進行睡眠
tb.sleeping = true
tb.sleepUntil = now + delta
unlock(tb.lock)
notetsleepg(tb.waitnote, delta) //睡眠delta時間,喚醒之后就可以執(zhí)行在堆頂?shù)亩〞r任務(wù)了
}
}
至此,time.Tick函數(shù)涉及到的主要功能就講解結(jié)束了,總結(jié)一下就是啟動定時任務(wù)時,會創(chuàng)建一個唯一協(xié)程,處理timer,所有的timer都在該協(xié)程中處理。
然后,我們再閱讀一下sleep的源碼實現(xiàn),核心源碼如下:
//go:linkname timeSleep time.Sleep
func timeSleep(ns int64) {
*t = timer{} //創(chuàng)建一個定時任務(wù)
t.when = nanotime() + ns //計算定時任務(wù)的執(zhí)行時間點
t.f = goroutineReady //執(zhí)行方法
tb.addtimerLocked(t) //加入timer堆,并在timer定時任務(wù)執(zhí)行協(xié)程中等待被執(zhí)行
goparkunlock(tb.lock, "sleep", traceEvGoSleep, 2) //睡眠,等待定時任務(wù)協(xié)程通知喚醒
}
讀了sleep的核心代碼之后,是不是突然發(fā)現(xiàn)和Tick函數(shù)的內(nèi)容很類似,都創(chuàng)建了timer,并加入了定時任務(wù)處理協(xié)程。神奇之處就在于,實際上這兩個函數(shù)產(chǎn)生的timer都放入了同一個timer堆,都在定時任務(wù)處理協(xié)程中等待被處理。
優(yōu)劣性對比,使用建議
現(xiàn)在我們知道了,Tick,Sleep,包括time.After函數(shù),都使用的timer結(jié)構(gòu)體,都會被放在同一個協(xié)程中統(tǒng)一處理,這樣看起來使用Tick,Sleep并沒有什么區(qū)別。
實際上是有區(qū)別的,Sleep是使用睡眠完成定時任務(wù),需要被調(diào)度喚醒。Tick函數(shù)是使用channel阻塞當(dāng)前協(xié)程,完成定時任務(wù)的執(zhí)行。當(dāng)前并不清楚golang 阻塞和睡眠對資源的消耗會有什么區(qū)別,這方面不能給出建議。
但是使用channel阻塞協(xié)程完成定時任務(wù)比較靈活,可以結(jié)合select設(shè)置超時時間以及默認(rèn)執(zhí)行方法,而且可以設(shè)置timer的主動關(guān)閉,以及不需要每次都生成一個timer(這方面節(jié)省系統(tǒng)內(nèi)存,垃圾收回也需要時間)。
所以,建議使用time.Tick完成定時任務(wù)。
補充:Golang 定時器timer和ticker
兩種類型的定時器:ticker和timer。兩者有什么區(qū)別呢?請看如下代碼:
ticker
package main
import (
"fmt"
"time"
)
func main() {
d := time.Duration(time.Second*2)
t := time.NewTicker(d)
defer t.Stop()
for {
- t.C
fmt.Println("timeout...")
}
}
output:
timeout…
timeout…
timeout…
解析
ticker只要定義完成,從此刻開始計時,不需要任何其他的操作,每隔固定時間都會觸發(fā)。
timer
package main
import (
"fmt"
"time"
)
func main() {
d := time.Duration(time.Second*2)
t := time.NewTimer(d)
defer t.Stop()
for {
- t.C
fmt.Println("timeout...")
// need reset
t.Reset(time.Second*2)
}
}
output:
timeout…
timeout…
timeout…
解析
使用timer定時器,超時后需要重置,才能繼續(xù)觸發(fā)。
ticker 例子展示
package main
import (
"fmt"
"time"
)
func main() {
t := time.NewTicker(3*time.Second)
defer t.Stop()
fmt.Println(time.Now())
time.Sleep(4*time.Second)
for {
select {
case -t.C:
fmt.Println(time.Now())
}
}
}
output:
2018-04-02 19:08:22.2797 +0800 CST
2018-04-02 19:08:26.3087 +0800 CST
2018-04-02 19:08:28.2797 +0800 CST
2018-04-02 19:08:31.2797 +0800 CST
2018-04-02 19:08:34.2797 +0800 CST
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。
您可能感興趣的文章:- 解決Golang time.Parse和time.Format的時區(qū)問題
- 解決golang時間字符串轉(zhuǎn)time.Time的坑
- golang的時區(qū)和神奇的time.Parse的使用方法
- 對Golang中的runtime.Caller使用說明
- Golang中的time.Duration類型用法說明
- golang time包做時間轉(zhuǎn)換操作
- golang xorm及time.Time自定義解決json日期格式的問題
- golang time常用方法詳解