回调从 C 进入 Go 时线程与运行时状态需要注意什么

我在接入带异步通知的 C 库时，最容易误判的一点是：回调“进入了 Go”，不等于它回到了发起调用的那个 goroutine，也不等于后续回调一定使用同一条操作系统线程。更稳妥的做法是把回调当成一个跨语言入口：让 cgo 负责接入运行时，让 C 负责自己的线程局部状态，让 Go 只接收已经复制好的数据。

结论是：只有 C 库明确要求固定线程状态时才考虑 runtime.LockOSThread；回调参数里的 C 内存要在回调内复制；Go 对象通过 runtime/cgo.Handle 间接映射；停止时必须先保证 C 不再回调，再删除句柄。

一、先把回调线程和 Go 运行时分开看

cgo 支持 C 调用带有 //export 的 Go 函数；C 如果需要函数指针，通常还要增加一个 C gateway。C 线程通过这个入口进入 Go 时，运行时会接管这次回调所需的上下文，但开发者不应把它当作某个固定 goroutine 的续接。同步回调可能发生在发起 C 调用的线程上，异步回调也可能来自 C 库自己创建的线程。

因此，回调入口适合做三件事：读取稳定的 C 参数、把必要数据复制到 Go 管理的内存、把任务交给 Go 协程。不要依赖“这次恰好还是同一线程”作为业务状态保存方案。

二、线程局部状态要由真正的拥有者管理

runtime.LockOSThread 的语义是把当前 goroutine 绑定到它当前所在的 OS 线程，直到配对的 UnlockOSThread。它适合 OpenGL 上下文、某些 GUI 线程或明确要求线程局部状态的原生库；它不能把所有未来的 C 异步回调强制安排到这条线程。

func runWithThreadState(start func() error) error {
    runtime.LockOSThread()
    defer runtime.UnlockOSThread() // 只有线程状态已恢复，才能解锁

    // 线程相关的 C 初始化必须发生在被绑定的线程上。
    if err := start(); err != nil {
        return fmt.Errorf("启动原生线程状态: %w", err)
    }
    return nil
}

如果线程状态是由 C 库创建并维护的，Go 侧不要假设在回调里锁一下就能恢复全部上下文。更可靠的边界是：让 C 提供线程初始化/清理接口，Go 只在文档明确要求时绑定线程，并记录每次回调是否带有可识别的上下文。

三、用句柄和拷贝守住数据生命周期

不能把 Go 函数值直接当成 C 函数指针传递。可以把回调对象放进 runtime/cgo.Handle，把整数句柄交给 C；回调真正收到的字节则应立即复制。这样 C 保存的是句柄和 C 自己拥有的指针，不是 Go 堆指针。

//export goOnEvent
func goOnEvent(h C.uintptr_t, data *C.char, n C.int) {
    // 先复制，避免把 C buffer 的生命周期带进 Go worker。
    payload := C.GoBytes(unsafe.Pointer(data), n)
    fn, ok := cgo.Handle(h).Value().(func([]byte))
    if !ok {
        return // 句柄类型不符时直接丢弃，避免回调线程 panic
    }
    fn(payload) // 生产代码可改为非阻塞投递到受控队列
}

句柄也有生命周期：同步 C 调用返回后可以删除句柄；异步库必须先调用 stop，再等待 join 或等价的“不会再回调”确认，最后才执行 Handle.Delete。提前删除会让迟到的 C 回调拿到失效映射。

四、让回调快速返回，再处理阻塞与重入

回调里做网络请求、磁盘写入或长时间加锁，会把 C 库的通知线程拖住，甚至造成 C 锁与 Go 锁相互等待。建议把回调拆成“校验长度—复制—投递”三段；队列满时要有明确策略，例如丢弃可重建事件、返回错误码，或使用有上限的阻塞时间。

还要检查 C 库是否允许回调重入：同一事件可能在锁内回调 Go，Go 再调用 C 就可能形成锁顺序反转。把原生调用、Go 队列和停止流程画成三个边界，比在回调里不断追加条件分支更容易排查。

五、发布前按这张清单检查

• 回调来自 Go 发起的同步调用，还是 C 自建线程的异步通知？
• 是否把 C 的 buffer、字符串或结构体指针保存到了回调之外？需要保存时是否已复制或改为 C 所有？
• 线程局部状态由谁初始化、谁清理，LockOSThread 是否成对且只包住必要范围？
• stop 之后是否真的等待到 C 不再回调，随后才删除 cgo.Handle？

一句话判断：线程身份是 C 库的契约，Go 运行时接入是 cgo 的职责，数据与句柄生命周期则必须由应用自己写清楚。把这三件事分开，异步回调的偶发崩溃通常会变成可定位的边界问题。

相关问题

回调里可以直接启动 goroutine 吗？

可以，但要先完成参数复制，并为停止阶段设计等待或取消机制；不要让新 goroutine 继续使用已经由 C 释放的地址。

什么时候一定要锁定 OS 线程？

只有底层 API 明确依赖线程局部状态时才锁定。普通 cgo 回调并不会因为没有 LockOSThread 就失去 Go 运行时支持。