您好,登錄后才能下訂單哦!
這篇文章主要介紹“go time.After性能怎么優(yōu)化”的相關(guān)知識,小編通過實(shí)際案例向大家展示操作過程,操作方法簡單快捷,實(shí)用性強(qiáng),希望這篇“go time.After性能怎么優(yōu)化”文章能幫助大家解決問題。
在項(xiàng)目中,基本都離不開需要休眠等待一定時(shí)間后再執(zhí)行下一步邏輯的操作,再搭配select,用起來是真的舒服。
func waitWorking() { select { case <-time.After(5 * time.Second): // 每隔5秒,主動向客戶端詢問任務(wù)狀態(tài) _ = receiver.CheckWorkingEventBus.Publish(receiver) case <-receiver.updated: } }
在這個(gè)示例中,5秒后會執(zhí)行Publish
函數(shù),或者<-receiver.updated
有數(shù)據(jù)時(shí)退出,這是我們比較常用的方式。
但有一點(diǎn)要注意的是:time.After如果沒有被執(zhí)行到,會導(dǎo)致無法第一時(shí)間GC回收內(nèi)存。
從內(nèi)存分析中,會看到內(nèi)存在持續(xù)增長,到了一定時(shí)間后,才會下降。這個(gè)增長幅度隨著你的項(xiàng)目請求量而決定。
這是因?yàn)楫?dāng)<-receiver.updated
被觸發(fā)執(zhí)行時(shí),導(dǎo)致time.After(5 * time.Second)
在5秒后才會有數(shù)據(jù)進(jìn)來,在這5秒內(nèi),time.After創(chuàng)建的NewTimer(d)是無法回收的。
func After(d Duration) <-chan Time { return NewTimer(d).C }
明白了這一點(diǎn)之后,我們可以簡單的做一個(gè)改進(jìn)
func waitWorking() { timer := time.NewTimer(5 * time.Second) select { case <-timer.C: // 每隔5秒,主動向客戶端詢問任務(wù)狀態(tài) _ = receiver.CheckWorkingEventBus.Publish(receiver) case <-receiver.updated: timer.Stop() } }
當(dāng)<-receiver.updated
被觸發(fā)執(zhí)行時(shí),我們主動調(diào)用Stop
方法,來告知GC,此timer對象不再使用。
這樣就不至于等到5秒后,GC才知道這個(gè)對象不再使用。
這就完了嗎?顯示沒有,如果waitWorking函數(shù)會在并發(fā)中被調(diào)用:
type TaskGroupMonitor struct { updated chan struct{} // 數(shù)據(jù)有更新,讓流程重置 name string // 任務(wù)名稱 } func (receiver *TaskGroupMonitor) waitWorking() { timer := time.NewTimer(5 * time.Second) select { case <-timer.C: // 每隔5秒,主動向客戶端詢問任務(wù)狀態(tài) _ = receiver.CheckWorkingEventBus.Publish(receiver) case <-receiver.updated: timer.Stop() } } func init() { // 模擬數(shù)據(jù)庫讀到了100條任務(wù) for i := 0; i < 100; i++ { taskGroup:= TaskGroupMonitor{} go taskGroup.waitWorking() } }
這里假如從數(shù)據(jù)庫中讀到了100條任務(wù)數(shù)據(jù),每條數(shù)據(jù)都在獨(dú)立的協(xié)程中運(yùn)行。
這就會導(dǎo)致在這100條任務(wù)在運(yùn)行的過程中,創(chuàng)建了100個(gè)time.Timer對象,事實(shí)上除了waitWorking
,還會有waitStart
,waitScheduler
,taskFinish
等函數(shù)也使用了time.Timer對象。
可以想到,項(xiàng)目在運(yùn)行過程中time.Timer在不停的創(chuàng)建,直到GC后才被回收。這將導(dǎo)致我們的內(nèi)存一直占用著。
并且time.After
或time.NewTicker
并不是高精度的時(shí)間控制。有時(shí)候會慢那么0-3ms,協(xié)程數(shù)量越多越繁忙,則越不精準(zhǔn)。
這對于調(diào)度中心而言是無法接收的,我的目標(biāo)是支持幾千個(gè)任務(wù)同時(shí)監(jiān)控調(diào)度。意味著協(xié)程數(shù)量會非常高。
而在GO的time.Timer中是使用64個(gè)timersBucket
,并使用四叉堆
來管理各個(gè)timer,雖然在1.17版本有所改進(jìn)。
但時(shí)間上仍然沒有那么準(zhǔn)確,對于調(diào)度這種場景來說,對ms級別的延遲也是沒辦法接受的。
time.Timer原理不在本篇的范圍內(nèi),現(xiàn)在有很多大神有這方面的剖析,感興趣可以去搜搜。
通過簡單的分析,我們已經(jīng)知道使用time.Timer會有如下缺點(diǎn):
每個(gè)協(xié)程需要?jiǎng)?chuàng)建time.Timer(導(dǎo)致內(nèi)存占用上升)
time.Timer會有延遲(對于ms敏感的場景不適用)
即如此,我們是否可以通過統(tǒng)一的時(shí)間管理器
來管理所有的時(shí)間觸發(fā)器呢?
答案是顯而易見的,那就是時(shí)間輪。
時(shí)間輪是一種實(shí)現(xiàn)延遲功能的算法, 它在Linux內(nèi)核中使用廣泛, 是Linux內(nèi)核定時(shí)器的實(shí)現(xiàn)方法和基礎(chǔ)之一. 時(shí)間輪是一種高效來利用線程資源來進(jìn)行批量化調(diào)度的一種調(diào)度模型, 把大量的調(diào)度任務(wù)全部綁定到同一個(gè)調(diào)度器上, 利用這個(gè)調(diào)度器來進(jìn)行所有任務(wù)的管理, 觸發(fā)以及運(yùn)行.
簡單來說,時(shí)間輪就是一個(gè)模擬時(shí)鐘的原理。 實(shí)現(xiàn)方式有:單層、雙層、多層三種方式。
而在雙層、多層時(shí)間輪中,又有兩種算法:一種是不管幾層,時(shí)間周期是一樣的。另一種是低層一圈 = 上層一格(像秒針、分針一樣)
在時(shí)鐘里,秒針走完一圈,分針走一格。分針走完一圈,時(shí)針走一格。以此類推。
當(dāng)秒針走到第X格,會到第X格的隊(duì)列中找到是否有待執(zhí)行任務(wù)列表,如果有則取出并通知到C變量。
而我在實(shí)現(xiàn)這個(gè)時(shí)間輪就是完全模擬時(shí)鐘的這種算法來實(shí)現(xiàn)的。我與其它開源的時(shí)間輪不一樣的地方是,我是高精度算法的。
時(shí)間輪的原理大概就講這么多,畢竟不是一個(gè)什么新鮮的算法,網(wǎng)上有很多講的比我更透徹的大神,在這里我主要講使用時(shí)間輪的前后對比。
我們來看看如何使用:
// 在項(xiàng)目中,定義一個(gè)全局變量tw,并規(guī)定第0層,走一格=100ms,一圈有120格 import "github.com/farseer-go/fs/timingWheel" var tw = timingWheel.New(100*time.Millisecond, 120) tw.Start()
接著在項(xiàng)目中我們改成時(shí)間輪來控制時(shí)間:
func (receiver *TaskGroupMonitor) waitWorking() { select { case <-tw.AddPrecision(60 * time.Second).C: _ = receiver.CheckWorkingEventBus.Publish(receiver) case <-receiver.updated: } }
至此,我們使用了全局tw變量來控制時(shí)間的延遲管理。
我們來看下,優(yōu)化前的情況:
100個(gè)并發(fā)下調(diào)度:平均延遲:10ms
、CPU:31.4%
、內(nèi)存:115m
優(yōu)化后:
100個(gè)并發(fā)下調(diào)度:平均延遲:1ms
、CPU:21.7%
、內(nèi)存:34.5m
為此,整體性能提升:34%
,內(nèi)存減少:67%
關(guān)于“go time.After性能怎么優(yōu)化”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識,可以關(guān)注億速云行業(yè)資訊頻道,小編每天都會為大家更新不同的知識點(diǎn)。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。