Go调度器通过GMP模型实现高效并发,G(goroutine)为轻量级任务,M(machine)为OS线程,P(processor)为逻辑处理器,三者协同完成任务调度;新goroutine优先加入P的本地队列,M绑定P后从中取任务执行,本地队列空时通过全局队列或工作窃取获取任务,保障负载均衡;当G阻塞于系统调用时,M与P解绑,P可被其他M绑定继续执行任务,避免CPU闲置;自Go 1.14起引入抢占式调度,防止长时间运行的G阻塞P,提升响应性;GOMAXPROCS默认设为CPU核心数,通常无需修改;优化并发性能需避免长时阻塞、合理使用channel、减少共享状态竞争,并借助pprof等工具分析瓶颈。

Golang的Go调度器,在我看来,是其并发模型的核心魅力所在。它通过一种用户态的、非抢占式(早期版本)和协作式(现在已加入抢占式补充)机制,巧妙地将大量的goroutine映射到少量操作系统线程上运行。你可以把它想象成一个高效的交通调度员,面对无数需要通行的车辆(goroutine),却只有有限的车道(OS线程),它通过精密的规则和快速的切换,确保每辆车都能在恰当的时候前进,同时最大限度地利用现有资源,避免交通堵塞。
Go调度器解决并发问题的核心在于其独特的GMP模型:Goroutine (G)、Machine (M) 和 Processor (P)。这个模型是Go语言能够实现“十万并发”的关键基石。
G (Goroutine):这是Go语言并发的最小执行单元。它不是操作系统线程,而是由Go运行时管理的轻量级线程。每个goroutine都有自己的栈,但这个栈非常小,并且可以按需动态扩容或收缩,大大降低了创建和销毁的开销。你可以启动成千上万个goroutine,而不会像操作系统线程那样迅速耗尽系统资源。对我来说,goroutine更像是一个“任务卡片”,上面写着要执行的代码和它当前的运行状态。
M (Machine/OS Thread):M代表一个真正的操作系统线程。它是操作系统能够调度的最小单位,也是实际执行Go代码的“工人”。一个M可以绑定一个P来执行其上的goroutine,也可以在没有P的情况下执行一些特殊的系统调用。当一个goroutine需要进行阻塞的系统调用(如网络I/O、文件读写)时,它会脱离当前的P,让M去处理这个系统调用。这时候,M就带着这个阻塞的goroutine一起“忙”去了,而P则可以立即找另一个M或者自己找一个空闲的M来继续执行其他goroutine。
立即学习“go语言免费学习笔记(深入)”;
P (Processor/Logical CPU):P是连接G和M的“桥梁”,或者说是一个“上下文”或“调度器”。它代表一个逻辑处理器,持有并管理一个本地的goroutine运行队列。P的主要职责是为M提供可运行的goroutine。操作系统线程M必须绑定一个P才能执行Go代码。P的数量通常由
GOMAXPROCS
整个调度流程大致是这样:新创建的goroutine会被放入P的本地运行队列。当一个M空闲时,它会尝试从P的本地队列中获取一个goroutine来执行。如果P的本地队列为空,M会尝试从全局运行队列中获取,或者更激进地,从其他P的本地队列中“窃取”一部分goroutine来执行。当一个goroutine执行完毕或者发生阻塞(如等待I/O),M会将其从P上解绑,P则可以立即选择下一个可运行的goroutine,并将其分配给另一个空闲的M(或者当前的M在处理完阻塞后重新绑定一个P)。这种快速切换和资源复用,正是Go调度器高效的秘诀。
GMP模型的核心在于它将并发任务的执行与底层的操作系统线程解耦,实现了一种用户态的、高效的调度。当我初次接触这个模型时,最大的感触就是它的“分工明确”和“弹性”。G是纯粹的任务,M是执行任务的劳力,而P则是管理和分配任务的“工头”。
一个P通常会维护一个本地的goroutine队列,新创建的或者从阻塞中恢复的goroutine,如果可能,会优先被放入当前P的本地队列。M会从它所绑定的P的本地队列中取出goroutine来执行。这种局部性原则大大减少了锁竞争,因为大多数时候,M只需要与它自己的P进行交互。
但当一个P的本地队列为空时,事情就变得有趣了。M并不会因此闲置,它会尝试从全局运行队列中获取goroutine。如果全局队列也空了,M会启动“工作窃取”(work stealing)机制:它会随机选择其他P,并从它们的本地队列中“偷取”一半的goroutine到自己的P的本地队列中。这种机制确保了所有P的负载尽可能均衡,避免了某些P“饿死”而另一些P“撑死”的情况,从而最大化地利用了CPU资源。
这种协调方式,在我看来,是Go调度器最聪明的地方之一。它既保持了本地性带来的高效,又通过全局队列和工作窃取机制解决了负载均衡的问题。它不是简单地把所有任务扔到一个大池子里让所有工人去抢,而是每个工头先管好自己手头的活,实在忙不过来或者闲下来了才去寻求帮助或帮助别人。
阻塞和负载均衡是并发编程中两个常见的难题,Go调度器在这方面有其独到之处。
如今有越来越多的人在网上做代驾,打造一个代驾平台,既可以让司机增加一笔额外的收入,也解决了车主酒后不能开发的问题,汉潮代驾系统基于微信小程序开发的代驾系统支持一键下单叫代驾,支持代驾人员保证金功能,支持代客下单,支持代驾人员订单调度及代驾人员位置查看,欢迎大家关注我们。 汉潮代驾系统是汉潮唐越科技有限公司研发团队自主开发的代驾系统,包含后台系统和微信小程序,主要功能模块商家设置,会员管理,营销管理
0
对于阻塞,Go调度器采取了一种非常灵活的策略。当一个goroutine执行到一个可能导致阻塞的操作(比如系统调用,如网络读写、文件I/O,或者等待一个channel操作),它不会阻塞整个M。相反,当前的M会把这个阻塞的goroutine从P上“摘下来”,然后将P释放出来,让其他M可以绑定这个P去执行其他可运行的goroutine。而那个带着阻塞goroutine的M,则会继续处理系统调用。一旦系统调用完成,那个goroutine就会被重新标记为可运行,并再次被放入某个P的运行队列中等待调度。
这种机制有效地避免了“M阻塞导致P空闲”的问题。设想一下,如果一个M阻塞了,它所绑绑定的P也跟着闲置,那么就浪费了一个CPU核心的计算能力。Go调度器通过这种“M-P解耦”的方式,确保了P(逻辑处理器)能够持续地为可运行的goroutine提供服务,从而最大限度地利用了CPU。
至于负载均衡,除了前面提到的工作窃取机制,Go调度器还引入了抢占式调度。在Go 1.14之前,调度是协作式的,意味着goroutine需要主动放弃CPU(例如通过函数调用、channel操作等)。如果一个goroutine执行了一个长时间的计算循环而没有进行任何可能导致调度的操作,它可能会长时间霸占一个P,导致其他goroutine“饥饿”。Go 1.14引入了基于信号的非协作式抢占,这意味着即使一个goroutine没有主动放弃CPU,调度器也能在一定时间后(通常是10ms)通过发送信号来中断它,强制它进行调度,从而确保所有goroutine都能获得执行机会,进一步提升了负载均衡和响应性。这对我来说是一个非常重要的改进,因为它解决了纯协作式调度可能带来的“恶意”或“无意”的goroutine霸占CPU的问题。
理解Go调度器的工作原理,最终目的还是为了更好地编写高性能的Go程序。虽然Go调度器在大多数情况下表现出色,但我们仍然可以通过一些实践和参数调整来进一步优化性能。
一个最直接的参数是
GOMAXPROCS
GOMAXPROCS
GOMAXPROCS
// 可以在程序启动时设置GOMAXPROCS,但通常不推荐手动设置 // 除非你非常清楚你在做什么 runtime.GOMAXPROCS(runtime.NumCPU()) // 默认行为
实践中,更重要的是设计层面的考量。
首先,要避免长时间阻塞的系统调用。虽然Go调度器能够处理阻塞,但频繁或长时间的阻塞仍然会带来额外的调度开销。如果你的goroutine需要执行长时间的外部调用(如调用外部API、数据库查询),考虑使用带有超时机制的上下文(
context.WithTimeout
其次,合理利用通道(channels)。通道是Go语言中goroutine之间通信和同步的推荐方式。它们不仅提供了安全的并发原语,其内部实现也与调度器紧密结合。当一个goroutine尝试向一个满的通道发送数据,或者从一个空的通道接收数据时,它会被阻塞,并由调度器进行管理。正确使用通道可以自然地引导调度器进行高效的上下文切换。
再者,警惕全局锁和共享状态。虽然Go调度器能够高效调度goroutine,但如果你的多个goroutine频繁地竞争同一个全局锁或者修改同一个共享变量,那么调度器的优势就会被锁竞争的开销所抵消。尽量设计无共享或者最小化共享状态的并发模式,使用
sync.Mutex
sync.RWMutex
最后,监控和分析是不可或缺的。Go提供了强大的工具链,如
pprof
以上就是Golang的Go调度器(scheduler)是如何管理和调度goroutine的的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号