Go第三方框架--ants协程池框架

fengzhuzhigu

已于 2024-04-10 22:34:34 修改

阅读量1k

点赞数 26

分类专栏： go 文章标签： golang 开发语言后端

于 2024-04-10 22:32:55 首次发布

本文链接：https://blog.csdn.net/u013915286/article/details/137376751

版权

go 专栏收录该内容

20 篇文章 0 订阅

订阅专栏

1. 背景介绍

1.1 goroutine

ants是站在巨人的肩膀上开发出来的，这个巨人是goroutine，这是连小学生都知道的事儿，那么为什么不继续使用goroutine(以下简称go协程)呢。这是个思考题，希望讲完本文大家可以有个答案。
go协程只涉及用户态的使用，不涉及内核态和两态的切换，所以非常轻便，通常一个协程大概只占用2k的内存，比线程更轻量级，而且其还有特别高效的GMP协程调度算法，使得go语言编写并发程序简单和高效。但是官方没有提供协程池包，虽然go协程有如此多的优点，go语言也支持垃圾自动回收，但是不断地对资源进行创建和回收是一种犯罪行为；为了更好的支持协程资源空间重复使用、并发控制、提升性能，并为开发者提供更简便和使用的功能，有大量的第三方协程池框架应运而生，ants是其中的佼佼者。

2. ants简介

ants是github托管的一个高效的协程池库，其star已经有12k了，足见其受欢迎的程度。本ants版本使用的是v2.8.2 目前最新版是2.9.1。其主要committer是潘建锋，根据公开资料（应该没侵犯隐私）曾任职腾讯，现在在亚马逊上班，未婚，个人博客。八卦完了，现在看看ants的发展史吧。ps：为了还原历史，下文引用ants的readme 相信很多博客都介绍过了，纯属凑字数。

2.1 简介

ants是一个高性能的 goroutine 池，实现了对大规模 goroutine 的调度管理、goroutine 复用，允许使用者在开发并发程序的时候限制 goroutine 数量，复用资源，达到更高效执行任务的效果。

2.2 功能

自动调度海量的 goroutines，复用 goroutines
定期清理过期的 goroutines，进一步节省资源
提供了大量有用的接口：任务提交、获取运行中的 goroutine 数量、动态调整 Pool 大小、释放 Pool、重启 Pool
优雅处理 panic，防止程序崩溃
资源复用，极大节省内存使用量；在大规模批量并发任务场景下比原生 goroutine 并发具有更高的性能
非阻塞机制

2.3 ants是如何运行的

流程图
在这里插入图片描述

2.4 使用

// demoPoolFunc1 执行任务
func demoPoolFunc1() {
	time.Sleep(2 * time.Millisecond)
}

// TestAntsPoolWaitToGetWorker ants运行简单例子.
func TestAntsPoolWaitToGetWorker(t *testing.T) {
	var wg sync.WaitGroup
	p, _ := NewPool(1000) // 初始化一个协程池 容量是 1000
	defer p.Release()     // 执行成功手动释放协程池

	for i := 0; i < 10000; i++ { // 启动10000个任务 让协程池来运行
		wg.Add(1)             // wg++
		_ = p.Submit(func() { // 提交任务
			demoPoolFunc1()
			wg.Done() // 完成后 wg--
		})
	}
	wg.Wait() // 阻塞等待任务完成
}

可以看到暴露给外面的就是图2.3的 pool池初始化、任务提交和pool池回收剩下的都在水面之下 . ps:submit 也可以使用协程启动这样下方代码中出现的锁就可以解释的通了。
以下源码讲解就拿上述代码为例子

ps: 还有一些内容请看客移步代码的readme

3. 几种重要的结构体

3.1 pool

pool核心结构体，其结构体如下

// Pool 接受来自客户端的任务，通过循环利用 goroutines 限制了总数量为给定值。
type Pool struct {
   // pool 的容量，负值表示 pool 容量无限，使用无限 pool 是为了避免由于 pool 的嵌套使用（向同一个 pool 提交任务，该任务又向同一个 pool 提交新任务）可能引起的无限阻塞问题。
   capacity int32
   
   // 当前运行的 goroutines（goworker的items长度） 数量。
   running int32
   
   // 保护 worker 队列的锁。
   lock sync.Locker

   // 存储可用 worker 的切片，是任务执行器的队列，是一个接口 
   workers workerQueue

   // 状态用于通知 pool 关闭自身。
   state int32

   // 等待获取空闲 worker 的条件。
   cond *sync.Cond

   // workerCache  池化技术 不断生成 新worker ， 但是他不是 2.3工作池。它在woker数量没达到容量阈值时，
   // 会不断生成。一旦达到了，就不会再工作，因为这时 workerStack 中的 items 满了后会自己维持（因为一般不会有过期，又有容量限制）,后续会讲解。
   // 直到将过期的worker放入队列时，woker数量减少，才又继续工作生成新的worker。但是 一般情况下 过期时间都特别长，当过期时间短时,
   // 工作池就是 workers + workerCache  这两个属性 在不断向items补充 gowoker。workers回收可用的goworker，workerCache 补齐不足容量的部分。
   // 但是一般不会让goworker过期，所以为了方便 我们一般吧 items叫做工作池
   workerCache sync.Pool

   // waiting 是已经在 pool.Submit() 上被阻塞的 goroutines 数量（因为本2.3例子没有使用协程提交submit,所以最大为1），受 pool.lock 保护。
   waiting int32

   purgeDone int32
   stopPurge context.CancelFunc // cancel 用来停止 goPurge 函数
   ticktockDone int32
   stopTicktock context.CancelFunc // cancel 用来停止 goTicktock 函数
   now atomic.Value  // 存储现在时间
	
	// 存放一些参数 过期时间 最大阻塞任务等
   options *Options

}

3.2 workerStack

任务的执行队列

type workerStack struct {
	items  []worker // 工作池， 对应 2.3 图中的 工作池 每个工作池 运行一个 协程 
	expiry []worker // 已经过期的任务执行器队列（工作池）
}

这个结构体实现了 workerQueue 结构体的接口也就是 3.1pool里的 workerQueue 。

type workerQueue interface {
	len() int
	isEmpty() bool
	insert(worker) error    // 向工作池中 加入一个 任务执行器
	detach() worker   // 从工作池中 拿到一个 任务执行器
	refresh(duration time.Duration) []worker //  清理掉过期的goworker
	reset()  // 重置 将所有goworker 任务执行完毕后 结束
}

接口中都是操作工作执行器（goworker）队列的一些函数

3.3 goWorker

goWorker 是实际任务执行器

// goWorker 是实际执行任务的执行器，
// 它启动一个 goroutine 来接受任务并执行函数调用。
type goWorker struct {
	// 拥有该 worker 的池 也就是 3.1中的 pool, 将pool传给 worker 以便调用pool的函数和属性。
	pool *Pool

	// task 存放 执行任务的chan。 将任务输送到chan来执行。
	task chan func()

	// lastUsed 在将 worker 放回队列时将更新，有多个任务则时间是最后一个任务执行时间。
	lastUsed time.Time
}

其实现了下面的 worker 结构体


type worker interface {
	run()   // 运行 goworker
	finish() // 让任务执行完毕后 结束goworker 
	lastUsedTime() time.Time
	inputFunc(func()) // 向 goworker 中的 chan 传递任务
	inputParam(interface{})
}

接口中都是操作工作执行器的一些函数

ps: 之所以需要执行器和其队列的接口是因为有不同的执行器和执行器队列，例如goWorkerWithFunc执行器和 loopQueue执行器队列，因为不是本文重点不做介绍，但其大体执行逻辑是一致的，感兴趣的看官可以自行研究。

如上我们就可以猜到执行的一个大体的脉络，控制逻辑是 pool–>workerStack（2.3中的工作池,主要是属性items）–>goworker（worker 任务执行器），接下来我们来看下源码验证下

4. ants 协程池初始化

见 2.4 代码部分 p, _ := NewPool(1000) ，这样可以初始化一个pool池。我们看下其源码，

// NewPool generates an instance of ants pool.
func NewPool(size int, options ...Option) (*Pool, error) {
	if size <= 0 {
		size = -1
	}

	opts := loadOptions(options...) // opts 没有传 跳过

	if !opts.DisablePurge { // 值是 true 走这里
		if expiry := opts.ExpiryDuration; expiry < 0 {
			return nil, ErrInvalidPoolExpiry
		} else if expiry == 0 {
			opts.ExpiryDuration = DefaultCleanIntervalTime // 过期时间
		}
	}

	if opts.Logger == nil { // logger 选择默认的
		opts.Logger = defaultLogger
	}

	p := &Pool{ // 初始化 pool 将size赋值给capacity
		capacity: int32(size),
		lock:     syncx.NewSpinLock(), // 这里是自己实现的指数退避的自旋锁，为啥要自己实现我想可能是官方的性能作者不满意吧 有空细研究下
		options:  opts,
	}
	p.workerCache.New = func() interface{} { //  从缓存池中可以获取新的 goworker
		return &goWorker{
			pool: p,
			task: make(chan func(), workerChanCap), // 创建一个 大小是1的任务chan，注意大小是0和1不一样，感兴趣的自行gpt3.5
		}
	}
	if p.options.PreAlloc { // false 不走这里
		if size == -1 {
			return nil, ErrInvalidPreAllocSize
		}
		p.workers = newWorkerQueue(queueTypeLoopQueue, size)
	} else {
		p.workers = newWorkerQueue(queueTypeStack, 0) // 初始化 workerStack(工作池) 结构体 大小是0
	}

	p.cond = sync.NewCond(p.lock)

	p.goPurge()    // 启动一个协程 不断检查执行器队列，将过期的执行器（goworker）的任务释放,任务对应的任务执行器放入 pool中，工作执行器协程退出；
	p.goTicktock() // 启动协程更新pool的时间，用来更新 goworker的最后使用时间

	return p, nil
}

到这里一个新的 pool就建立起来了，这其中需要进一步剖析的是 p.goPurge() 其值得关注的调用链如下

在这里插入图片描述

purgeStaleWorkers（ctx context.Context）函数代码如下

// 启动一个协程 不断检查执行器队列，将过期的执行器的任务释放,任务对应的任务执行器放入 workercache 中，工作执行器协程退出；
func (p *Pool) purgeStaleWorkers(ctx context.Context) {
	ticker := time.NewTicker(p.options.ExpiryDuration) // 使用过期时间 建一个 ticker

	defer func() {
		ticker.Stop()
		atomic.StoreInt32(&p.purgeDone, 1)
	}()

	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C: // 到了过期时间 就开始执行 查找过期woker的逻辑
		}

		if p.IsClosed() {
			break
		}

		var isDormant bool
		p.lock.Lock()                                               //  为什么加锁  (因为submit可以使用 协程启动) 
		staleWorkers := p.workers.refresh(p.options.ExpiryDuration) // 将 items里面 过期的任务队列 复制到 expires队列里 并 返回
		n := p.Running()
		isDormant = n == 0 || n == len(staleWorkers)
		p.lock.Unlock()

		// Notify obsolete workers to stop.
		// This notification must be outside the p.lock, since w.task
		// may be blocking and may consume a lot of time if many workers
		// are located on non-local CPUs.
		for i := range staleWorkers { // 将过期队列 依次调用 finish() 使得本 woker停止（因为本worker的任务执行完毕后 会 阻塞，当调用finish（）时，会给chan传递一个 nil 使得任务停止 详细 请看 worker.run()） 并加入workercache 中
			staleWorkers[i].finish()
			staleWorkers[i] = nil
		}

		// There might be a situation where all workers have been cleaned up (no worker is running),
		// while some invokers still are stuck in p.cond.Wait(), then we need to awake those invokers.
		if isDormant && p.Waiting() > 0 { // 如果 不存在运行的协程（调用 run()会启动一个协程 数量 跟执行器相等 可以看做一个协程就是一个运行着的执行器 也就是 len(items)），或者 等待的协程>1 就广播 通知等待的协程来运行（主要是来提交任务）
			p.cond.Broadcast()
		}
	}
}

到这里 goPurge()就讲解完毕了。

5. 任务提交

任务提交到任务处理的调用链如下
在这里插入图片描述

run 函数是具体执行任务的函数，它启动一个协程来处理submit函数提交的任务
池化完毕后就是任务提交 p.Submit(…），这是核心执行逻辑见 2.3 中提交后后续的执行逻辑都在这个函数里。老规矩，我们继续追踪源码

5.1 任务提交

func (p *Pool) Submit(task func()) error {  // 其接受一个 任意类型的 任务 
	if p.IsClosed() {      // 如果协程池关闭了 则报错
		return ErrPoolClosed
	}

	w, err := p.retrieveWorker()  // 获取一个工作执行器（用 goworker 简称），规则：大体逻辑 如果工作池有，就拿来用，如果没有就新建（还有阻塞等）见 2.3流程图
	if w != nil {
		w.inputFunc(task)  // 将 任务 加入到 获取的 goworker 的任务chan 中（这时 goworker的run()函数可能正在 chan处阻塞），开始执行任务。大家思考下这边会不会阻塞？？ 
	}
	return err
}

其中 retrieveWorker() (w worker, err error) 函数如下

5.2 任务获取

// 这个应该是核心执行逻辑，返回一个可以使用的w或者阻塞
// retrieveWorker returns an available worker to run the tasks.
func (p *Pool) retrieveWorker() (w worker, err error) {
	p.lock.Lock() 

retry:
	// First try to fetch the worker from the queue.
	if w = p.workers.detach(); w != nil { //  items(工作池) 头部goworker出栈 赋值给 w,如果有空闲的w(w!=nil) 则返回
		p.lock.Unlock()
		//  为什么得到 w 后不run() 而是直接返回   ps: 因为只要可以获取到 工作执行器 则 必定 有一个 协程正在运行，否则这个执行器就是过期的退出了 不在 items中。
		return
	}

	// If the worker queue is empty and we don't run out of the pool capacity,
	// then just spawn a new worker goroutine.
	// 如果工作队列是空的或者 正在跑的 协程数（items大小）没达到 容量，任务刚启动时，会走这边，一旦items满了后，基本不走这边 要么从 items直接获取任务（上面代码），要么阻塞（下方代码 p.addWaiting）
	if capacity := p.Cap(); capacity == -1 || capacity > p.Running() {
		p.lock.Unlock()
		w = p.workerCache.Get().(*goWorker) // 从pool缓冲池中获取一个 工作队列，注意 workerCache 不是工作池，而是 对应2.3 “新启动一个 woker 来执行任务 ”的前半句话。
		w.run()  // 这边 开始 启动协程 处理 任务。思考题：items数量和协程数量是否是一致的（一致）
		return
	}

	// Bail out early if it's in nonblocking mode or the number of pending callers reaches the maximum limit value.
	if p.options.Nonblocking || (p.options.MaxBlockingTasks != 0 && p.Waiting() >= p.options.MaxBlockingTasks) { 
		p.lock.Unlock()
		return nil, ErrPoolOverload
	}

	// Otherwise, we'll have to keep them blocked and wait for at least one worker to be put back into pool.
	p.addWaiting(1) //能走到这里，证明items 达到最大容量了。
	p.cond.Wait()   // block and wait for an available worker// 程序阻塞等待唤醒，任务执行完毕或者goworker过期都会唤醒。
	p.addWaiting(-1)

	if p.IsClosed() {
		p.lock.Unlock()
		return nil, ErrPoolClosed
	}

	goto retry  // 被唤醒后 走到 retry 重新开始 为任务选 gowoker
}

在上述代码 w = p.workerCache.Get().(*goWorker) 处，我们可以发现，每次从缓存池获取一个 goworker 都要调用 run()函数，来启动goworker，这个函数才是执行任务的核心代码。它会启动一个协程并采用chan阻塞等待任务得到来。下面介绍run()函数

5.3 任务执行

这里开始执行任务

func (w *goWorker) run() {
	w.pool.addRunning(1) // 运行的 goworker 数量+1
	go func() {
		defer func() { // 当 goworker过期 或者 批量任务执行完毕 调用 p.Release()， 下方 for 循环 退出，然后则调用 本defer
			w.pool.addRunning(-1)     // 正在运行的 goworker 数量-1
			w.pool.workerCache.Put(w) // 将不用的 goworker 放入 缓存池中
			if p := recover(); p != nil {
				if ph := w.pool.options.PanicHandler; ph != nil {
					ph(p)
				} else {
					w.pool.options.Logger.Printf("worker exits from panic: %v\n%s\n", p, debug.Stack())
				}
			}
			// Call Signal() here in case there are goroutines waiting for available workers.
			w.pool.cond.Signal() // 唤醒一个 在 retrieveWorker（）函数 中 代码	p.cond.Wait()  处阻塞的程序，开始提交任务
		}()

		for f := range w.task { // 从 5.1submit()函数的 inputFunc(func())调用 处获取任务

			if f == nil { // 如果 chan 传递的是 nil (调用 finish())，则这个goworker退出
				return
			}
			f()                                    // 开始执行任务 执行2.4中例子中的 demoPoolFunc1()
			if ok := w.pool.revertWorker(w); !ok { // 任务执行完毕，将本goworker 入栈 items ，这时 协程不退出 继续for循环,这边就实现了 重复利用。
				return
			}
		}
	}()
}

任务执行完成后，对应的goworker需要入栈在代码 w.pool.revertWorker(w) 处执行，下面介绍下这个函数

5.4 工作执行器（goworker）入栈

本小结主要是将闲下来的goworker入栈涉及到 revertWorker(worker *goWorker) 函数，其代码如下：

// revertWorker puts a worker back into free pool, recycling the goroutines.
// 直接翻译： 将goworker放入 items中，循环使用这个协程
func (p *Pool) revertWorker(worker *goWorker) bool {
	if capacity := p.Cap(); (capacity > 0 && p.Running() > capacity) || p.IsClosed() { 
		p.cond.Broadcast()
		return false
	}

	worker.lastUsed = p.nowTime() //  更新goWorker协程的最后使用时间

	p.lock.Lock()
	// To avoid memory leaks, add a double check in the lock scope.
	// Issue: https://github.com/panjf2000/ants/issues/113
	if p.IsClosed() {
		p.lock.Unlock()
		return false
	}
	if err := p.workers.insert(worker); err != nil { // 将 goWorker 入栈
		p.lock.Unlock()
		return false
	}
	// Notify the invoker stuck in 'retrieveWorker()' of there is an available worker in the worker queue.
	p.cond.Signal() /// 唤醒一个 在 retrieveWorker（）函数 中 代码	p.cond.Wait()  处阻塞的程序（如果是协程启动的submit，则将此协程唤醒）
	p.lock.Unlock()

	return true
}

到此我们2.3的流程图涉及到的所有模块都梳理完毕，接下来就等着任务执行完毕后，将协程池释放。

6. 协程池释放

释放所有跟pool相关的资源，我们来梳理下有几处在运行或阻塞的程序
a. 提交任务时，当多于items容量时，阻塞在 5.2 函数的 p.cond.Wait() 处（要是submit是协程提交的话这里阻塞更多,，现在最多阻塞1个）
b. 新建池时启动的两个协程见标题4
c. submit提交任务时，启动的 items里的协程
所以有四处需要关闭，我们看下源码

func (p *Pool) Release() {
	if !atomic.CompareAndSwapInt32(&p.state, OPENED, CLOSED) { // 使用 cas算法 将 pool状态 修改为关闭，为续资源关闭做准备。
	    // 则所有协程任务执行完毕后，入 items 队列时会退出见 revertWorker() 函数 第一行）
	 	// 所有阻塞的协程 会退出（见 5.2 retrieveWorker()函数 最后部分 p.IsClosed()),其他见 对 p.IsClosed() 的调用
		return
	}

	if p.stopPurge != nil { // 停止 goPurge()函数 对应 --> b
		p.stopPurge()
		p.stopPurge = nil
	}
	p.stopTicktock() //  对应 --> b
	p.stopTicktock = nil

	p.lock.Lock()
	p.workers.reset() // 将所有goworker停止 对应 --> c
	p.lock.Unlock()
	// There might be some callers waiting in retrieveWorker(), so we need to wake them up to prevent
	// those callers blocking infinitely.
	p.cond.Broadcast() // 广播给 在 p.cond.wait()处阻塞的协程 继续运行，后续调用 p.IsClosed()退出。 这里对应   --> a

到这里ants的真个生命流程就梳理完毕了。

7.总结

感觉还是得梳理源码，才能有长进。这次只是梳理了最常用的核心部分，还有其他一些功能或结构体没有梳理到，希望有时间再添加吧。由于本人水平有限，本次梳理难免有疏漏，还请各位大佬指正，互相学习，谢谢。

fengzhuzhigu

关注

26
点赞
踩
24

收藏

觉得还不错? 一键收藏
0
评论
Go第三方框架--ants协程池框架

ants是站在巨人的肩膀上开发出来的，这个巨人是goroutine，这是连小学生都知道的事儿，那么为什么不继续使用goroutine(以下简称go协程)呢。这是个思考题，希望讲完本文大家可以有个答案。go协程只涉及用户态的使用，不涉及内核态和两态的切换，所以非常轻便，通常一个协程大概只占用2k的内存，比线程更轻量级，而且其还有特别高效的GMP协程调度算法，使得go语言编写并发程序简单和高效。
复制链接

扫一扫