本文深入探讨go语言协程的调度机制，解释为何看似简单的无限循环可能导致其他协程无法执行，形成阻塞。我们将阐述go的协作式调度模型，列举协程何时会主动让出cpu，并提供通过`runtime.gosched()`解决cpu密集型任务阻塞的实践方法，同时澄清`gomaxprocs`在解决此类问题中的局限性，旨在帮助开发者编写高效、无阻塞的go并发程序。
Go协程的意外阻塞现象
在Go语言中，协程（goroutine）是实现并发的核心机制，它们轻量且高效。然而，不恰当的协程设计，特别是CPU密集型任务，可能会导致意想不到的阻塞行为。考虑以下代码示例：
package mainimport ( "fmt" "time")func main() { timeout := make(chan int) go func() { time.Sleep(time.Second) // 协程A：1秒后发送信号 timeout <- 1 }() res := make(chan int) go func() { for { // 协程B：无限循环，不进行任何I/O或调度点操作 } res <- 1 // 此行代码永远不会执行到 }() select { case <-timeout: fmt.Println("timeout") case <-res: fmt.Println("res") }}
这段代码的预期行为可能是1秒后打印”timeout”，但实际运行结果却是程序会一直运行，没有任何输出。这是因为在main函数启动的两个协程中，协程B进入了一个无限循环，且循环体内部没有任何操作会主动让出CPU。这种行为在Go的调度模型下，会导致协程A（负责发送timeout信号）无法获得执行机会，从而造成整个程序的阻塞。
Go协程的协作式调度模型
Go语言的调度器采用的是协作式（Cooperative Scheduling）调度模型。这意味着一个协程必须主动或被动地将执行权交还给调度器，其他协程才有机会运行。与抢占式调度不同，协作式调度不会在任意时间点强制中断一个正在运行的协程，除非该协程执行了特定的操作。
因此，当一个协程进入一个不间断的CPU密集型循环时，它会持续占用分配给它的逻辑处理器（P），直到该协程完成或主动让出。在上述示例中，协程B的无限循环正是这种不让出CPU的典型场景，导致调度器无法将执行权分配给协程A。
协程何时会主动让出CPU
Go协程并非完全不让出CPU，它们会在以下几种情况下主动或被动地将执行权交还给调度器：
无缓冲通道的发送/接收操作（unbuffered chan send/recv）: 当协程尝试对无缓冲通道进行发送或接收操作，且没有对应的接收方或发送方时，协程会阻塞并让出CPU。系统调用（syscalls）: 包括文件读写、网络I/O等操作。当协程发起系统调用时，Go运行时会将其标记为阻塞，并调度其他协程运行。内存分配（memory allocation）: 涉及到堆内存分配时，Go运行时可能会触发调度。time.Sleep()调用: 明确调用time.Sleep()会使当前协程休眠指定时间，并让出CPU。runtime.Gosched()调用: 这是一个显式的调度点，强制当前协程让出CPU，让调度器有机会运行其他可运行的协程。
在上述阻塞示例中，协程B的无限循环内部没有包含上述任何一种让出CPU的操作，因此它会一直“霸占”CPU，直到程序被外部终止。
解决CPU密集型任务阻塞：使用runtime.Gosched()
对于那些必须进行CPU密集型计算且无法避免长时间运行的循环，我们可以通过显式调用runtime.Gosched()来解决阻塞问题。runtime.Gosched()函数会暂停当前协程的执行，将其放回可运行队列的末尾，并允许调度器运行其他协程。
修改后的代码示例如下：
package mainimport ( "fmt" "runtime" // 导入runtime包 "time")func main() { timeout := make(chan int) go func() { time.Sleep(time.Second) timeout <- 1 }() res := make(chan int) go func() { for { runtime.Gosched() // 在循环内部显式让出CPU // 可以在这里执行一些CPU密集型计算 } res <- 1 }() select { case <-timeout: fmt.Println("timeout") case <-res: fmt.Println("res") }}
通过在协程B的无限循环中添加runtime.Gosched()，协程B会在每次循环迭代时主动让出CPU，使得协程A有机会被调度执行，从而在1秒后成功打印”timeout”。
注意事项：
runtime.Gosched()适用于CPU密集型任务，但如果你的协程本身就包含I/O操作或通道通信，通常不需要手动调用它，因为这些操作本身就是调度点。过度频繁地调用runtime.Gosched()可能会引入不必要的上下文切换开销，应根据实际情况权衡。
GOMAXPROCS的误区与局限性
GOMAXPROCS环境变量用于设置Go程序可以使用的操作系统线程的最大数量。一个常见的误解是，增加GOMAXPROCS可以解决协程阻塞问题。虽然增加GOMAXPROCS确实可以让更多的Go调度器（M）与逻辑处理器（P）绑定，从而允许更多的协程并发地在不同的OS线程上运行，但这并不能根本解决一个CPU密集型协程不让出CPU的问题。
即使设置GOMAXPROCS等于CPU核心数，如果一个CPU密集型协程仍然不包含任何调度点，它仍然可能长时间占用一个逻辑处理器，导致其他需要该逻辑处理器的协程无法运行。更重要的是，Go的垃圾回收器（GC）在执行”stop-the-world”阶段时，会暂停所有协程的执行。如果一个高CPU利用率的协程从不让出CPU，那么GC可能永远无法完成其”stop-the-world”阶段，导致GC本身被阻塞，进而影响整个程序的健康运行。
因此，GOMAXPROCS主要用于控制Go程序可以利用的并行度，而不是解决单个协程内部的调度问题。对于CPU密集型协程，关键在于确保它们能周期性地让出CPU。
总结与最佳实践
理解Go协程的协作式调度模型对于编写高效、无阻塞的并发程序至关重要。
设计原则： 编写协程时，应确保它们能够周期性地让出CPU。这通常通过包含I/O操作、通道通信、time.Sleep()或显式调用runtime.Gosched()来实现。避免无限循环： 尽量避免在协程中创建不包含任何调度点的无限循环。如果必须有，请务必在循环内部添加runtime.Gosched()。利用Go的并发原语： Go提供的通道（channel）和sync包中的并发原语（如Mutex、WaitGroup）通常都内置了调度点，合理使用它们可以自然地实现协程间的协作和调度。性能考量： 对于真正的CPU密集型任务，除了让出CPU外，还可以考虑将其分解为更小的任务，或者使用工作池等模式来管理并发。
通过遵循这些原则，开发者可以更好地驾驭Go的并发能力，构建健壮且响应迅速的应用程序。
以上就是Go协程调度深度解析：理解与规避CPU密集型任务阻塞的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1415501.html
微信扫一扫 
支付宝扫一扫 
