Golang用WaitGroup控制goroutine执行方法
今日不肯埋头,明日何以抬头!每日一句努力自己的话哈哈~哈喽,今天我将给大家带来一篇《Golang如何用WaitGroup控制goroutine执行》,主要内容是讲解等等,感兴趣的朋友可以收藏或者有更好的建议在评论提出,我都会认真看的!大家一起进步,一起学习!
WaitGroup通过Add、Done、Wait方法实现并发任务同步,确保所有goroutine完成后再继续主程序,相比time.Sleep更可靠,比直接使用channel更简洁高效。

Golang中的WaitGroup,在我看来,它是处理并发任务同步的利器,尤其是当你需要确保所有后台任务都完成之后,主程序才能继续执行或退出时。它就像一个计数器,你启动了多少个并发任务,就给它加上多少,每个任务完成时就减去一个,直到计数归零,主程序就知道可以安全地前进了。
解决方案
要使用WaitGroup管理多goroutine执行,核心在于三个方法:Add(delta int)、Done()和Wait()。它的工作机制其实非常直观:
- 初始化:首先创建一个
sync.WaitGroup实例。 - 计数增加:每当你准备启动一个新的goroutine时,调用
wg.Add(1)来增加计数器。这一步至关重要,必须在go关键字之前完成,否则可能会出现竞态条件,导致Wait()过早返回。 - 任务完成:在每个goroutine内部,确保任务执行完毕后调用
wg.Done()。这会将计数器减一。通常,我们会利用defer wg.Done()来保证无论goroutine是否发生panic,计数器都能被正确减去。 - 等待完成:在主goroutine中,调用
wg.Wait()。这个方法会阻塞当前goroutine,直到WaitGroup的计数器归零。
这是一个典型的使用示例:
package main
import (
"fmt"
"sync"
"time"
)
func worker(id int, wg *sync.WaitGroup) {
defer wg.Done() // 确保无论如何,任务完成时计数器都会减一
fmt.Printf("Worker %d starting...\n", id)
time.Sleep(time.Duration(id) * time.Second) // 模拟耗时操作
fmt.Printf("Worker %d finished.\n", id)
}
func main() {
var wg sync.WaitGroup
numWorkers := 3
fmt.Println("Main: Starting workers...")
for i := 1; i <= numWorkers; i++ {
wg.Add(1) // 启动前增加计数
go worker(i, &wg)
}
fmt.Println("Main: Waiting for workers to complete...")
wg.Wait() // 阻塞直到所有worker完成
fmt.Println("Main: All workers completed. Exiting.")
}为什么直接使用time.Sleep()或channel不能有效管理并发任务?
在我刚接触Go并发编程的时候,也曾天真地尝试过time.Sleep()。你可能会想,我启动了几个goroutine,估摸着它们大概需要多久,然后主程序就time.Sleep(那个估摸的时间)。但很快就会发现,这种做法非常脆弱,简直是“碰运气”:
- 不确定性:并发任务的执行时间是不确定的,受CPU调度、I/O阻塞等多种因素影响。你设定的
Sleep时间可能太短,导致部分任务还没完成主程序就退出了;也可能太长,白白浪费了等待时间。这根本不是一个可靠的同步机制。 - 资源浪费:如果你的
Sleep时间过长,那么主goroutine就会长时间空闲,白白占用系统资源,降低程序效率。 - 无法处理错误:如果某个goroutine因为错误提前退出,或者执行时间远超预期,
time.Sleep()对此一无所知,也无法做出任何响应。
至于channel,它确实是Go并发编程的核心原语,功能强大,可以用于通信和协调。但对于“等待所有任务完成”这种特定场景,直接用channel来实现,反而会显得有些“杀鸡用牛刀”,代码会更复杂:
你可能需要为每个goroutine创建一个chan struct{}或者chan bool,然后每个goroutine完成时发送一个信号,主goroutine再循环接收这些信号。虽然可行,但相比WaitGroup的简洁明了,它引入了额外的通道管理开销和逻辑复杂度,特别是在任务数量不确定时,管理起来会比较繁琐。WaitGroup就是为了这种“计数等待”的场景而生的,它把这种模式抽象得非常优雅。
WaitGroup的Add()、Done()和Wait()方法各自扮演什么角色,以及它们的使用陷阱?
WaitGroup的这三个方法,构成了其工作的核心循环。理解它们各自的职责和潜在的陷阱,是正确使用它的关键。
Add(delta int):这个方法用于增加WaitGroup的内部计数器。delta通常是正数,表示要等待的goroutine数量。- 角色:它告诉
WaitGroup,“嘿,我这里有delta个新的任务要启动了,你得等它们。” - 陷阱:必须在启动goroutine之前调用
Add()。如果你在go worker()之后才调用wg.Add(1),那么主goroutine和Add()的调用之间就可能存在竞态条件。如果worker执行得非常快,甚至在Add()被调用之前就完成了并调用了Done(),那么WaitGroup的计数器就可能永远不会达到正确的值,或者Wait()可能会过早地返回。一个常见的错误是把wg.Add(1)放在go func() { ... }()的匿名函数内部,这是错误的,因为匿名函数在另一个goroutine中执行,这又回到了竞态条件的问题。
- 角色:它告诉
Done():这个方法用于减少WaitGroup的内部计数器。它等同于Add(-1)。- 角色:它告诉
WaitGroup,“我这个任务已经完成了,你可以把计数器减一了。” - 陷阱:确保每个
Add()都有对应的Done()被调用。如果某个goroutine没有调用Done()(比如因为panic没有被defer捕获,或者逻辑分支遗漏),那么WaitGroup的计数器将永远不会归零,导致wg.Wait()永远阻塞,造成死锁。因此,强烈建议使用defer wg.Done()来确保Done()总能被调用。另一个不常见的陷阱是,如果在Done()之后再次对同一个WaitGroup调用Add(),可能会导致计数器为负数,这会引发panic。
- 角色:它告诉
Wait():这个方法会阻塞调用它的goroutine,直到WaitGroup的内部计数器归零。- 角色:它是一个屏障,确保所有被
Add()标记的任务都已通过Done()完成。 - 陷阱:
Wait()只能在计数器归零后解除阻塞。如果在计数器还没有归零时再次调用Wait(),它会继续阻塞。另外,Wait()不应该在循环中重复调用,因为它会阻塞,直到所有任务完成,之后再次调用将立即返回。
- 角色:它是一个屏障,确保所有被
在实际项目中,除了WaitGroup,还有哪些Go并发原语可以辅助管理复杂场景?
在实际的Go项目中,并发场景往往比简单的“等待所有任务完成”要复杂得多。这时,WaitGroup虽然好用,但它只是工具箱中的一个。我们还需要依赖其他Go并发原语来构建健壮、高效的并发系统。
context.Context:这几乎是现代Go服务中处理并发任务取消、超时和传递请求范围值的标准方式。当我们需要在一个复杂的调用链中,从父goroutine向子goroutine传递取消信号,或者设置一个全局的请求超时时,context就显得不可或缺。比如,你启动了一个耗时的数据处理goroutine,但用户取消了请求,你就可以通过context.WithCancel创建的Context来通知数据处理goroutine优雅地退出,而不是让它一直运行下去。WaitGroup只管等待,Context则管协调和控制生命周期。sync.Mutex和sync.RWMutex:当多个goroutine需要访问和修改共享数据时,如果没有适当的同步机制,就会出现数据竞态,导致不可预测的结果。sync.Mutex(互斥锁)提供了一种独占访问共享资源的方式,任何时候只有一个goroutine可以持有锁并访问数据。sync.RWMutex(读写互斥锁)则更进一步,它允许多个goroutine同时读取数据(共享锁),但在写入时会独占(排他锁)。这在读多写少的场景下,能显著提升并发性能。我的经验是,只要涉及共享可变状态,锁几乎是必不可少的。
channel:虽然前面提到channel不适合简单的等待所有任务完成,但它在goroutine之间的通信和编排(orchestration)方面是无与伦比的。- 数据传递:goroutine之间安全地传递数据。
- 任务编排:控制任务的执行顺序,比如一个任务的输出作为另一个任务的输入。
- 信号通知:例如,一个goroutine完成某个阶段性工作后,通过
channel通知另一个goroutine可以开始下一个阶段。 - 限流:使用带缓冲的
channel可以实现工作池或并发限流,控制同时运行的goroutine数量,防止资源耗尽。
在我看来,构建一个复杂的并发系统,往往是这些原语的组合拳。WaitGroup处理“等待完成”,Context处理“取消/超时”,Mutex处理“共享数据安全”,而Channel则负责“通信与编排”。理解它们的适用场景和局限性,才能写出真正健壮和高效的Go并发代码。
终于介绍完啦!小伙伴们,这篇关于《Golang用WaitGroup控制goroutine执行方法》的介绍应该让你收获多多了吧!欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识,快来关注吧!
JavaStack类常用方法详解
- 上一篇
- JavaStack类常用方法详解
- 下一篇
- 蓝屏0x0000008e怎么解决
-
- Golang · Go教程 | 17小时前 | map · 并发安全 · RWMutex · sync.Map · Go教程 · 并发安全 RWMutex sync.Map Go map并发读写 go test race
- Go map 并发读写崩溃怎么办:从复现报错到 RWMutex 修复的完整流程
- 272浏览 收藏
-
- Golang · Go教程 | 2天前 | singleflight · 并发控制 · Go教程 · 缓存治理 · 接口优化 · Go 并发请求 缓存击穿 singleflight 缓存回填
- Go singleflight 防缓存击穿实战:相同请求只查一次数据库
- 114浏览 收藏
-
- Golang · Go教程 | 3天前 | golang
- Go 线上故障复盘模板:日志、指标、链路追踪与 pprof 证据闭环
- 710浏览 收藏
-
- Golang · Go教程 | 3天前 | golang
- Go 微服务超时、重试与熔断观测:避免故障放大的实践
- 687浏览 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 485次学习
-
- 剧云
- 剧云是专业中文剧本创作平台,安全稳定运行十余年,集成AI编剧、剧本医生审核、人物小传、剧情关系图、大纲编写、多人协作、Word导入导出、版权管控功能,数据安全防护,轻松高效创作剧本。
- 133次使用
-
- 万象有声
- 万象有声,一个专为有声创作者打造的新一代智能有声内容创作平台。平台提供专业的智能拆章、智能画本编辑、AI配音、AI生成音效、后期制作、智能对轨、智能审听等有声创作全流程工具,可以帮助创作者高效、低成本创作出引人入胜的有声作品。立即体验,让有声书制作更简单!
- 138次使用
-
- Red Skill
- 小红书创作服务平台为小红书创作者和机构提供视频上传、数据分析、粉丝管理、创作指导等多项运营服务,助力用户解锁更多创作者专属功能,体验高效创作!
- 142次使用
-
- MiMo Code
- MiMo Code 是小米大模型团队开源的新一代 AI 编程助手,面向开发者提供代码理解、生成与辅助开发能力,适合作为 AI 编程工具收藏和体验。
- 247次使用
-
- TRAE Work
- TRAE AI IDE | 国内首款 AI 原生集成开发环境,深度集成 Doubao-1.5-pro 与 DeepSeek 模型,支持中文自然语言一键生成完整代码框架,实时预览前端效果并智能修复 BUG。首创 Builder 模式实现需求到代码的自动化开发,兼容 Windows/macOS 系统,官网下载即用。
- 272次使用
-
- Java 性能优化上线清单:从定位、改造到灰度发布
- 2026-06-11 860浏览
-
- Spring Boot 压测验证:Gatling、JMeter 与性能回归门禁
- 2026-06-11 843浏览
-
- Java NMT 非堆内存排查:Direct Buffer、线程栈与 Metaspace 分析
- 2026-06-11 826浏览
-
- Spring Boot 容器内存优化:JVM 堆、非堆与 MaxRAMPercentage
- 2026-06-11 809浏览
-
- Tomcat 连接与线程参数调优:maxThreads、acceptCount 与 KeepAlive
- 2026-06-11 792浏览

