Go timer 是如何被调度的？

hi，你们好，我是 haohongfan。web

本篇文章剖析下 Go 定时器的相关内容。定时器不论是业务开发，仍是基础架构开发，都是绕不过去的存在，因而可知定时器的重要程度。微信

咱们无论用 NewTimer, timer.After，仍是 timer.AfterFun 来初始化一个 timer, 这个 timer 最终都会加入到一个全局 timer 堆中，由 Go runtime 统一管理。session

全局的 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)app

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 了性能。svg

四叉堆其实就是四叉树，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 基本已经结束了，有想跟我讨论的能够在留言区评论。

Go timer 完整流程图获取连接：连接: 连接: https://pan.baidu.com/s/1nUvTK_0qBlwbS6LbZXKM7g 密码: t219 其余模块流程图，请关注公众号 HHFCodeRv 回复1获取。

更多学习学习资料分享，关注公众号回复指令：

回复 0，获取《Go 面经》
回复 1，获取《Go 源码流程图》

本文分享自微信公众号 - HHFCodeRv（hhfcodearts）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。