Go timer 是如何被調度的？

hi，大家好，我是 haohongfan。

本篇文章剖析下 Go 定時器的相關內容。定時器不管是業務開發，還是基礎架構開發，都是繞不過去的存在，由此可見定時器的重要程度。

我們不管用 NewTimer, timer.After，還是 timer.AfterFun 來初始化一個 timer, 這個 timer 最終都會加入到一個全局 timer 堆中，由 Go runtime 統一管理。

全局的 timer 堆也經歷過三個階段的重要升級。

• Go 1.9 版本之前，所有的計時器由全局唯一的四叉堆維護，協程間競爭激烈。

• Go 1.10 - 1.13，全局使用 64 個四叉堆維護全部的計時器，沒有本質解決 1.9 版本之前的問題

• Go 1.14 版本之後，每個 P 單獨維護一個四叉堆。

Go 1.14 以後的 timer 性能得到了質的飛昇，不過伴隨而來的是 timer 成了 Go 裏面最複雜、最難梳理的數據結構。本文不會詳細分析每一個細節，我們從大體來了解 Go timer 的工作原理。

1. 使用場景

Go timer 在我們代碼中會經常遇到。

場景 1：RPC 調用的防超時處理（下面代碼節選 dubbogo)

func (c *Client) Request(request *remoting.Request, timeout time.Duration, response *remoting.PendingResponse) error {
    _, session, err := c.selectSession(c.addr)
    // .. 省略
    if totalLen, sendLen, err = c.transfer(session, request, timeout); err != nil {
        if sendLen != 0 && totalLen != sendLen {
          // .. 省略
        }
        return perrors.WithStack(err)
    }

    // .. 省略
    select {
    case <-getty.GetTimeWheel().After(timeout):
        return perrors.WithStack(errClientReadTimeout)
    case <-response.Done:
        err = response.Err
    }
    return perrors.WithStack(err)
}

場景 2：Context 的超時處理

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel()
    go doSomething()
    
    select {
    case <-ctx.Done():
        fmt.Println("main", ctx.Err())
    }
}

2. 圖解源碼

2.1 四叉堆原理

timer 的全局堆是一個四叉堆，特別是 Go 1.14 之後每個 P 都會維護着一個四叉堆，減少了 Goroutine 之間的併發問題，提升了 timer 了性能。

四叉堆其實就是四叉樹，Go timer 是如何維護四叉堆的呢？

• Go runtime 調度 timer 時，觸發時間更早的 timer，要減少其查詢次數，儘快被觸發。所以四叉樹的父節點的觸發時間是一定小於子節點的。

• 四叉樹顧名思義最多有四個子節點，爲了兼顧四叉樹插、刪除、重排速度，所以四個兄弟節點間並不要求其按觸發早晚排序。

這裏用兩張動圖簡單演示下 timer 的插入和刪除

把 timer 插入堆

把 timer 從堆中刪除

2.2 timer 是如何被調度的？

• 調用 NewTimer，timer.After, timer.AfterFunc 生產 timer, 加入對應的 P 的堆上。

• 調用 timer.Stop, timer.Reset 改變對應的 timer 的狀態。

• GMP 在調度週期內中會調用 checkTimers ，遍歷該 P 的 timer 堆上的元素，根據對應 timer 的狀態執行真的操作。

2.3 timer 是如何加入到 timer 堆上的？

把 timer 加入調度總共有下面幾種方式：

• 通過 NewTimer, time.After, timer.AfterFunc 初始化 timer 後，相關 timer 就會被放入到對應 p 的 timer 堆上。

• timer 已經被標記爲 timerRemoved，調用了 timer.Reset(d)，這個 timer 也會重新被加入到 p 的 timer 堆上

• timer 還沒到需要被執行的時間，被調用了 timer.Reset(d)，這個 timer 會被 GMP 調度探測到，先將該 timer 從 timer 堆上刪除，然後重新加入到 timer 堆上

• STW 時，runtime 會釋放不再使用的 p 的資源，p.destroy()->timer.moveTimers，將不再被使用的 p 的 timers 上有效的 timer(狀態是：timerWaiting，timerModifiedEarlier，timerModifiedLater) 都重新加入到一個新的 p 的 timer 上

2.4 Reset 時 timer 是如何被操作的？

Reset 的目的是把 timer 重新加入到 timer 堆中，重新等待被觸發。不過分爲兩種情況：

• 被標記爲 timerRemoved 的 timer，這種 timer 是已經從 timer 堆上刪除了，但會重新設置被觸發時間，加入到 timer 堆中

• 等待被觸發的 timer，在 Reset 函數中只會修改其觸發時間和狀態（timerModifiedEarlier 或 timerModifiedLater）。這個被修改狀態的 timer 也同樣會被重新加入到 timer 堆上，不過是由 GMP 觸發的，由 checkTimers 調用 adjusttimers 或者 runtimer 來執行的。

2.5 Stop 時 timer 是如何被操作的？

time.Stop 爲了讓 timer 停止，不再被觸發，也就是從 timer 堆上刪除。不過 timer.Stop 並不會真正的從 p 的 timer 堆上刪除 timer，只會將 timer 的狀態修改爲 timerDeleted。然後等待 GMP 觸發的 adjusttimers 或者 runtimer 來執行。

真正刪除 timer 的函數有兩個 dodeltimer，dodeltimer0。

2.6 Timer 是如何被真正執行的？

timer 的真正執行者是 GMP。GMP 會在每個調度週期內，通過 runtime.checkTimers 調用 timer.runtimer(). timer.runtimer 會檢查該 p 的 timer 堆上的所有 timer，判斷這些 timer 是否能被觸發。

如果該 timer 能夠被觸發，會通過回調函數 sendTime 給 Timer 的 channel C 發一個當前時間，告訴我們這個 timer 已經被觸發了。

如果是 ticker 的話，被觸發後，會計算下一次要觸發的時間，重新將 timer 加入 timer 堆中。

3. Timer 使用中的坑

確實 timer 是我們開發中比較常用的工具，但是 timer 也是最容易導致內存泄露，CPU 狂飆的殺手之一。

不過仔細分析可以發現，其實能夠造成問題就兩個方面：

• 錯誤創建很多的 timer，導致資源浪費

• 由於 Stop 時不會主動關閉 C，導致程序阻塞

3.1 錯誤創建很多 timer，導致資源浪費

func main() {
    for {
        // xxx 一些操作
        timeout := time.After(30 * time.Second)
        select {
        case <- someDone:
            // do something
        case <-timeout:
            return
        }
    }
}

上面這段代碼是造成 timer 異常的最常見的寫法，也是我們最容易忽略的寫法。

造成問題的原因其實也很簡單，因爲 timer.After 底層是調用的 timer.NewTimer，NewTimer 生成 timer 後，會將 timer 放入到全局的 timer 堆中。

for 會創建出來數以萬計的 timer 放入到 timer 堆中，導致機器內存暴漲，同時不管 GMP 週期 checkTimers，還是插入新的 timer 都會瘋狂遍歷 timer 堆，導致 CPU 異常。

要注意的是，不只 time.After 會生成 timer, NewTimer，time.AfterFunc 同樣也會生成 timer 加入到 timer 中，也都要防止循環調用。

解決辦法: 使用 time.Reset 重置 timer，重複利用 timer。

我們已經知道 time.Reset 會重新設置 timer 的觸發時間，然後將 timer 重新加入到 timer 堆中，等待被觸發調用。

func main() {
    timer := time.NewTimer(time.Second * 5)    
    for {
        timer.Reset(time.Second * 5)

        select {
        case <- someDone:
            // do something
        case <-timer.C:
            return
        }
    }
}

3.2 程序阻塞，造成內存或者 goroutine 泄露

func main() {
    timer1 := time.NewTimer(2 * time.Second)
    <-timer1.C
    println("done")
}

上面的代碼可以看出來，只有等待 timer 超時 "done" 纔會輸出，原理很簡單：程序阻塞在 <-timer1.C 上，一直等待 timer 被觸發時，回調函數 time.sendTime 纔會發送一個當前時間到 timer1.C 上，程序才能繼續往下執行。

不過使用 timer.Stop 的時候就要特別注意了，比如：

func main() {
    timer1 := time.NewTimer(2 * time.Second)
    go func() {
        timer1.Stop()
    }()
    <-timer1.C

    println("done")
}

程序就會一直死鎖了，因爲 timer1.Stop 並不會關閉 channel C，使程序一直阻塞在 timer1.C 上。

上面這個例子過於簡單了，試想下如果 <- timer1.C 是阻塞在子協程中，timer 被的 Stop 方法被調用，那麼子協程可能就會被永遠的阻塞在那裏，造成 goroutine 泄露，內存泄露。

Stop 的正確的使用方式：

func main() {
    timer1 := time.NewTimer(2 * time.Second)
    go func() {
        if !timer1.Stop() {
            <-timer1.C
        }
    }()

    select {
    case <-timer1.C:
        fmt.Println("expired")
    default:
    }
    println("done")
}

到此，Go timer 基本已經結束了，有想跟我討論的可以在留言區評論。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/iseiQ20eIUR9i02fy1tFhg