Golang中WASM协程调度器是如何工作的

Golang中WASM协程调度器是如何工作的 你好！

解释：

我刚开始将我的一款业余游戏移植到WASM。

到目前为止体验非常出色。😄 几小时内就让大部分功能运行起来，看起来非常有前景。

但在游戏运行几分钟/几秒钟后，就遇到了这些我无法理解的死锁。运行时并未将其报告为死锁，但它直接冻结了我的浏览器。（所有主流浏览器情况相同）

推测：

该游戏在许多其他平台上都能正常运行，并且有多个后端，所以我相当确定这只是WASM后端的问题。

由于运行时并未将此死锁报告为“死锁：所有goroutine均处于休眠状态”，我认为在从我的WASM代码调用JS或启动新的goroutine时，需要考虑一些因素。

问题：

如果我理解正确，“WASM标准”不支持/定义操作系统线程？那么运行时中goroutine是如何被复用的？是否存在一些我需要考虑的限制？

运行时能否处理两个处于紧密循环中的goroutine？（抢占式多任务） 这对我来说似乎行不通。看起来只有一个紧密循环会向控制台打印信息。 我尝试过在紧密循环中使用runtime.Gosched() 和select语句（带default分支），但似乎只有一个在执行。


更多关于Golang中WASM协程调度器是如何工作的的实战教程也可以访问 https://www.itying.com/category-94-b0.html

1 回复

更多关于Golang中WASM协程调度器是如何工作的的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


在Go的WebAssembly（WASM）环境中，协程调度器的工作方式与标准Go运行时有所不同，主要因为WASM执行环境不支持真正的操作系统线程。以下我将详细解释WASM中goroutine的调度机制、潜在的死锁问题，以及如何优化代码以避免这些问题。

WASM中goroutine调度的工作原理

在WASM中，Go运行时使用一个单线程的事件循环来模拟多线程环境。WASM标准不提供对操作系统线程的直接支持，因此Go的WASM后端通过JavaScript事件循环（如浏览器中的事件循环）来复用goroutine。具体来说：

  • 单线程执行：所有goroutine在单个JavaScript线程上运行，通过协作式调度（cooperative scheduling）切换。这意味着goroutine必须主动让出控制权，否则可能阻塞整个执行。
  • 抢占式调度限制：在标准Go环境中，运行时使用抢占式调度（例如基于时间片的抢占），但在WASM中，由于环境限制，抢占可能不完全有效。goroutine只有在调用特定函数（如通道操作、time.Sleep或显式调用runtime.Gosched()）时才会让出控制权。
  • 事件驱动：当goroutine调用JavaScript函数或等待外部事件（如定时器或DOM事件）时，控制权会返回给JavaScript事件循环，允许其他goroutine运行。

潜在死锁原因和解决方案

从你的描述看，死锁可能源于goroutine在紧密循环中没有适当让出控制权，导致其他goroutine无法执行。运行时未报告死锁，因为goroutine可能处于“可运行”状态但未被调度，这不同于所有goroutine休眠的典型死锁。

示例：紧密循环中的调度问题

在WASM中，如果一个goroutine在紧密循环中不主动让出控制权，它可能独占执行时间，导致其他goroutine饥饿。例如，以下代码可能只有一个goroutine输出：

package main

import (
    "fmt"
    "runtime"
)

func main() {
    go func() {
        for {
            fmt.Println("Goroutine 1")
            // 如果没有让出控制权，可能阻塞其他goroutine
        }
    }()
    
    go func() {
        for {
            fmt.Println("Goroutine 2")
            // 同样问题
        }
    }()
    
    select {} // 阻止主goroutine退出
}

在WASM中，这可能导致只有一个goroutine持续执行，因为运行时无法强制抢占。

优化紧密循环：使用runtime.Gosched()或通道

为了确保公平调度，你需要在循环中定期让出控制权。使用runtime.Gosched()或非阻塞操作（如带default分支的select）可以有所帮助，但需注意在WASM中这些方法可能不如预期有效，因为调度是协作式的。以下是改进示例：

package main

import (
    "fmt"
    "runtime"
)

func main() {
    done := make(chan bool)
    
    go func() {
        for {
            select {
            case <-done:
                return
            default:
                fmt.Println("Goroutine 1")
                runtime.Gosched() // 显式让出控制权
            }
        }
    }()
    
    go func() {
        for {
            select {
            case <-done:
                return
            default:
                fmt.Println("Goroutine 2")
                runtime.Gosched() // 显式让出控制权
            }
        }
    }()
    
    // 运行一段时间后退出示例
    go func() {
        <-time.After(2 * time.Second)
        close(done)
    }()
}

在这个例子中，runtime.Gosched()提示调度器切换goroutine，但WASM中其效果可能有限，因为调度依赖于JavaScript事件循环。

处理JavaScript交互

当从WASM调用JavaScript时，控制权会暂时交给JavaScript环境。如果JavaScript代码同步执行长时间操作，它可能阻塞Go调度器。确保JavaScript调用是异步的或使用回调机制，以避免阻塞。例如，使用syscall/js包进行异步调用：

package main

import "syscall/js"

func main() {
    // 示例：异步调用JavaScript函数
    js.Global().Call("setTimeout", js.FuncOf(func(this js.Value, args []js.Value) interface{} {
        // 回调逻辑
        return nil
    }), 1000)
}

总结

在WASM中，goroutine调度依赖于协作式模型，而非真正的抢占。如果你的游戏涉及紧密循环，确保在循环中集成让出控制权的机制，如定期调用runtime.Gosched()或使用通道和select语句。此外，避免在Go代码中执行长时间同步操作，并利用JavaScript的异步特性。通过这些调整，你可以减少死锁风险并改善多goroutine行为。如果问题持续，考虑使用Go的WASM特定工具（如-tags=wasm）进行调试，或检查运行时版本以获取更新调度改进。

回到顶部