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
环境变量决定，默认情况下等于系统的CPU核心数。P的存在，有效地避免了M之间对全局goroutine队列的竞争，提高了调度的效率。
整个调度流程大致是这样：新创建的goroutine会被放入P的本地运行队列。当一个M空闲时，它会尝试从P的本地队列中获取一个goroutine来执行。如果P的本地队列为空，M会尝试从全局运行队列中获取，或者更激进地，从其他P的本地队列中“窃取”一部分goroutine来执行。当一个goroutine执行完毕或者发生阻塞（如等待I/O），M会将其从P上解绑，P则可以立即选择下一个可运行的goroutine，并将其分配给另一个空闲的M（或者当前的M在处理完阻塞后重新绑定一个P）。这种快速切换和资源复用，正是Go调度器高效的秘诀。
Golang的GMP模型如何协调并发任务？
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调度器如何处理阻塞和负载均衡？
阻塞和负载均衡是并发编程中两个常见的难题，Go调度器在这方面有其独到之处。
对于阻塞，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的问题。
优化Golang并发性能：调度器参数与实践建议
理解Go调度器的工作原理，最终目的还是为了更好地编写高性能的Go程序。虽然Go调度器在大多数情况下表现出色，但我们仍然可以通过一些实践和参数调整来进一步优化性能。
一个最直接的参数是
GOMAXPROCS
。它控制了Go运行时可以使用的P的数量。默认情况下，
GOMAXPROCS
被设置为机器的CPU核心数。这意味着Go运行时会尝试并行地利用所有可用的CPU核心。在绝大多数情况下，保持默认值是最好的选择。如果你将其设置得过小，可能会导致CPU资源利用不足；如果设置得过大，则可能导致过多的上下文切换开销，反而降低性能。我个人的经验是，除非你对你的应用有非常深入的理解，并且通过基准测试验证了修改
GOMAXPROCS
能带来收益，否则就让它保持默认。
// 可以在程序启动时设置GOMAXPROCS，但通常不推荐手动设置// 除非你非常清楚你在做什么runtime.GOMAXPROCS(runtime.NumCPU()) // 默认行为
实践中，更重要的是设计层面的考量。
首先，要避免长时间阻塞的系统调用。虽然Go调度器能够处理阻塞，但频繁或长时间的阻塞仍然会带来额外的调度开销。如果你的goroutine需要执行长时间的外部调用（如调用外部API、数据库查询），考虑使用带有超时机制的上下文（
context.WithTimeout
）或者异步处理，以避免单个goroutine长时间阻塞。
其次，合理利用通道（channels）。通道是Go语言中goroutine之间通信和同步的推荐方式。它们不仅提供了安全的并发原语，其内部实现也与调度器紧密结合。当一个goroutine尝试向一个满的通道发送数据，或者从一个空的通道接收数据时，它会被阻塞，并由调度器进行管理。正确使用通道可以自然地引导调度器进行高效的上下文切换。
再者，警惕全局锁和共享状态。虽然Go调度器能够高效调度goroutine，但如果你的多个goroutine频繁地竞争同一个全局锁或者修改同一个共享变量，那么调度器的优势就会被锁竞争的开销所抵消。尽量设计无共享或者最小化共享状态的并发模式，使用
sync.Mutex
、
sync.RWMutex
时要审慎，并考虑使用通道进行数据传递而非直接共享内存。
最后，监控和分析是不可或缺的。Go提供了强大的工具链，如
pprof
，可以帮助你分析CPU使用、内存分配、goroutine阻塞等问题。通过这些工具，你可以深入了解你的应用程序的运行时行为，发现潜在的性能瓶颈，并针对性地进行优化。有时候，性能问题并不是调度器本身的效率低下，而是你的代码逻辑导致了不必要的阻塞或者过度的资源竞争。
以上就是Golang的Go调度器(scheduler)是如何管理和调度goroutine的的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1405472.html
微信扫一扫 
支付宝扫一扫 
