纯净、安全、绿色的下载网站

首页|软件分类|下载排行|最新软件|IT学院

当前位置:首页IT学院IT技术

Go timer 调度 Go timer怎样调度

haohongfan   2021-06-09 我要评论
想了解Go timer怎样调度的相关内容吗haohongfan在本文为您仔细讲解Go timer 调度 的相关知识和一些Code实例欢迎阅读和指正我们先划重点:Go,timer,调度,Go,timer下面大家一起来学习吧

本篇文章剖析下 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 是如何被调度的?

调用 NewTimertimer.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(状态是:timerWaitingtimerModifiedEarliertimerModifiedLater) 都重新加入到一个新的 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 的函数有两个 dodeltimerdodeltimer0

2.6 Timer 是如何被真正执行的?

timer 的真正执行者是 GMPGMP 会在每个调度周期内通过 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.NewTimerNewTimer 生成 timer 后会将 timer 放入到全局的 timer 堆中

for 会创建出来数以万计的 timer 放入到 timer 堆中导致机器内存暴涨同时不管 GMP 周期 checkTimers还是插入新的 timer 都会疯狂遍历 timer 堆导致 CPU 异常

要注意的是不只 time.After 会生成 timer, NewTimertime.AfterFunc 同样也会生成 timer 加入到 timer 中也都要防止循环调用

解决办法: 使用 time.Reset 重置 timer重复利用 timer

我们已经知道 time.Reset 会重新设置 timer 的触发时间然后将 timer 重新加入到 timer 堆中等待被触发调用

func main() {
    timer := time.NewTimer(time.Second * 5)    
    for {
        t.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")
}

相关文章

猜您喜欢

  • @NotBlank不生效 怎样解决@NotBlank不生效的问题

    想了解怎样解决@NotBlank不生效的问题的相关内容吗Eddie-Wang在本文为您仔细讲解@NotBlank不生效的相关知识和一些Code实例欢迎阅读和指正我们先划重点:@NotBlank不生效,@NotBlank下面大家一起来学习吧..
  • Python提取Chrome浏览器保存的密码 怎样使用Python提取Chrome浏览器保存的密码

    想了解怎样使用Python提取Chrome浏览器保存的密码的相关内容吗刘润森!在本文为您仔细讲解Python提取Chrome浏览器保存的密码的相关知识和一些Code实例欢迎阅读和指正我们先划重点:Python提取Chrome浏览器保存的密码,Python提取浏览器密码下面大家一起来学习吧..

网友评论

Copyright 2020 www.fresh-weather.com 【世纪下载站】 版权所有 软件发布

声明:所有软件和文章来自软件开发商或者作者 如有异议 请与本站联系 点此查看联系方式