go time.After优化后性能提升34%内存减少67%

目录

• 正文
• 改进1：
• 分析问题
• 时间轮

正文

大家好，今天给大家带来一篇如何优化time.After函数。

最近我在做调度中心2.0的重构。本次重构使用的GO语言开发。

在项目中，基本都离不开需要休眠等待一定时间后再执行下一步逻辑的操作，再搭配select，用起来是真的舒服。

func waitWorking() {
    select {
    case <-time.After(5 * time.Second): // 每隔5秒，主动向客户端询问任务状态
        _ = receiver.CheckWo编程客栈rkingEventBus.Publish(receiver)
    case <-receiver.updated:
    }
}

在这个示例中，5秒后会执行Publish函数，或者<-receiver.updated有数据时退出，这是我们比较常用的方式。

但有一点要注意的是：time.After如果没有被执行到，会导致无法第一时间GC回收内存。

从内存分析中，会看到内存在持续增长，到了一定时间后，才会下降。这个增长幅度随着你的项目请求量而决定。

这是因为当<-receiver.updated被触发执行时，导致time.After(5 * time.Second)在5秒后才会有数据进来，在这5秒内，time.After创建的NewTimer(d编程客栈)是无法回收的。

func After(d Duration) <-chan Time {
    return NewTimer(d).C
}

明白了这一点之后，我们可以简单的做一个改进

改进1：

func waitWorking() {
    timer := time.NewTimer(5 * time.Second)
    select {
    case <-timer.C: // 每隔5秒，主动向客户端询问任务状态
        _ = receiver.CheckWorkingEventBus.Publish(receiver)
    case <-receiver.updated:
        timer.Stop()
    }
}

当<-receiver.updated被触发执行时，我们主动调用Stop方法，来告知GC，此timer对象不再使用。

这样就不至于等到5秒后，GC才知道这个对象不再使用。

这就完了吗？显示没有，如果waitWorking函数会在并发中被调用：

type TaskGroupMonitor struct {
    updated chan struct{}   // 数据有更新，让流程重置
   name    string          // 任务名称
}
func (receiver *TaskGroupMonitor) waitWorking() {
    timer := time.NewTimer(5 * time.Second)
    select {
    case <-timer.C: // 每隔5秒，主动向客户端询问任务状态
        _ = receiver.CheckWorkingEventBus.Publish(receiver)
    case <-receiver.updated:
        timer.Stop()
    }
}

func init() {
   // 模拟数据库读到了100条任务
    for i := 0; i < 100; i++ {
      taskGroup:= TaskGroupMonitor{}
        go taskGroup.waitWorking()
    }
}

这里假如从数据库中读到了100条任务数据，每条数据都在独立的协程中运行。

这就会导致在这100条任务在运行的过程中，创建了100个time.Timer对象，事实上除了waitWorking，还会有waitStart，waitScheduler，taskFinish等函数也使用了time.Timer对象。

可以想到，项目在运行过程中time.Timer在不停的创建，直到GC后才被回收。这将导致我们的内存一直占用着。

并且time.After或time.NewTicker并不是高精度的时间控制。有时候会慢那么0-3ms，协程数量越多越繁忙，则越不精准。

这对于调度中心而言是无法接收的，我的目标是支持几千个任务同时监控调度。意味着协程数量会非常高。

而在GO的time.Timer中是使用64个timersBucket，并使用四叉堆来管理各个timer，虽然在1.17版本有所改进。

但时间上仍然没有那么准确，对于调度这种场景来说，对ms级别的延迟也是没办法接受的。

time.Timer原理不在本篇的范围内，现在有很多大神有这方面的剖析，感兴趣可以去搜搜。

分析问题

通过简单的分析，我们已经知道使用time.Timer会有如下缺点：

• 每个协程需要创建time.Timer（导致内存占用上升）
• time.Timer会有延迟（对于ms敏感的场景不适用）

即如此，我们是否可以通过统一的时间管理器来管理所有的时间触发器呢？

答案是显而易见的，那就是时间轮。

时间轮

时间轮是一种实现延迟功能的算法, 它在linux内核中使用广泛, 是Linux内核定时器的实现方法和基础之一. javascript时间轮是一种高效来利用线程资源来进行批量化开发者_JAV培训调度的一种调度模型, 把大量的调度任务全部绑定到同一个调度器上, 利用这个调度器来进行所有任务的管理, 触发以及运行.

简单来说，时间轮就是一个模拟时钟的原理。 实现方式有：单层、双层、多层三种方式。

而在双层、多层时间轮中，又有两种算法：一种是不管几层，时间周期是一样的。另一种是低层一圈 = 上层一格（像秒针、分针一样）

在时钟里，秒针走完一圈，分针走一格。分针走完一圈，时针走一格。以此类推。

当秒针走到第X格，会到第X格的队列中找www.devze.com到是否有待执行任务列表，如果有则取出并通知到C变量。

而我在实现这个时间轮就是完全模拟时钟的这种算法来实现的。我与其它开源的时间轮不一样的地方是，我是高精度算法的。

时间轮的原理大概就讲这么多，毕竟不是一个什么新鲜的算法，网上有很多讲的比我更透彻的大神，在这里我主要讲使用时间轮的前后对比。

我们来看看如何使用：

// 在项目中，定义一个全局变量tw，并规定第0层，走一格=100ms，一圈有120格
import "github.com/farseer-go/fs/timingWheel"

var tw = timingWheel.New(100*time.Millisecond, 120)
tw.Start()

接着在项目中我们改成时间轮来控制时间：

func (receiver *TaskGroupMonitor) waitWorking() {
   select {
   case <-tw.AddPrecision(60 * time.Second).C:
        _ = receiver.CheckWorkingEventBus.Publish(receiver)
   case <-receiver.updated:
   }
}

至此，我们使用了全局tw变量来控制时间的延迟管理。

我们来看下，优化前的情况：

100个并发下调度：平均延迟：10ms、CPU：31.4%、内存：115m

优化后：

100个并发下调度：平均延迟：1ms、CPU：21.7%、内存：34.5m

为此，整体性能提升：34%，内存减少：67%

相关材料：

• farseer-go开源地址：github.com/farseer-go/…
• 时间轮开源地址：github.com/farseer-go/…
• 调度中心开源地址：github.com/FSchedandroidule/F…

以上就是go time.After优化后性能提升34%内存减少67%的详细内容，更多关于go time.After优化性能内存的资料请关注我们其它相关文章！