在 go 中调用 c 函数不会阻塞调度器，其他 goroutine 仍可正常运行；但该 goroutine 在阻塞较久时会临时“退出” gomaxprocs 并发限制，从而允许新 goroutine 启动。
Go 的运行时调度器（GMP 模型）对 C 语言调用做了专门优化，使其与 Erlang 的 NIF（Native Implemented Function）行为有本质区别：Go 中的 C 调用不会导致整个 OS 线程或调度器被独占阻塞。
当一个 goroutine 执行 cgo 调用进入 C 代码时：
- 初始阶段，该 goroutine 仍占用一个逻辑处理器（P），计入 GOMAXPROCS 的并发上限；
- 若 C 函数执行时间较长（例如进行系统调用、文件 I/O 或密集计算），Go 的后台监控协程 sysmon 会在约 20 微秒后检测到阻塞；
- 此时运行时会将该 P 与当前 M（OS 线程）解绑，并将 P 重新分配给其他就绪的 goroutine —— 即该 C 调用“让出”了 P，不再参与 GOMAXPROCS 的计数约束。
这意味着：
✅ 多个 goroutine 可并行执行（即使部分在跑 C 代码）；
✅ 长时间 C 调用不会拖垮整体并发吞吐；
⚠️ 但频繁或过长的 C 调用仍可能增加调度开销、引发 P 频繁切换，影响性能可预测性。
示例代码如下：
// #include <unistd.h>
import "C"
import (
"fmt"
"runtime"
"time"
)
func callSleepInC() {
C.usleep(1000000) // sleep 1s in C
}
func main() {
runtime.GOMAXPROCS(1) // 强制单 P
go func() {
fmt.Println("Goroutine A starting C call...")
callSleepInC()
fmt.Println("Goroutine A done")
}()
go func() {
// 此 goroutine 在 A 执行 C sleep 期间仍有机会被调度（尤其 >20μs 后）
time.Sleep(10 * time.Millisecond)
fmt.Println("Goroutine B executed concurrently!")
}()
time.Sleep(2 * time.Second)
}? 注意：此行为依赖于 Go 运行时的具体实现细节（如 sysmon 的轮询周期、阻塞判定阈值等），不同 Go 版本可能存在微调，不应作为稳定调度语义依赖。若需严格控制并发或避免 C 调用干扰，建议：将耗时 C 调用封装为独立子进程或服务；使用 runtime.LockOSThread() 仅在必要时绑定线程（慎用，易引发死锁）；通过 debug.SetGCPercent(-1) 等方式辅助诊断调度行为（仅限调试）。
总之，Go 对 cgo 的调度支持是其“混合编程友好性”的关键设计之一——既保留 C 的性能与生态，又不牺牲 Go 原生并发模型的轻量与弹性。
