解读

Go 1.19 默认把基于信号的异步抢占扩展到所有平台（此前只在部分 Unix 平台开启）。当 Go 调度器需要把某个 M（线程）从当前 goroutine 上“抢”出来时，会向该 M 发送 SIGURG；运行时收到信号后，在信号处理函数里把当前寄存器上下文保存到 g0 栈，再切换到调度器逻辑。
一旦 M 正在执行 C 代码（cgo），信号也会毫无差别地打到这条线程上。由于 C 侧完全感知不到 Go 的调度契约，就产生了若干副作用。国内面试中，面试官想确认候选人是否真在现网踩过坑：能否准确说出“副作用表现 → 根因 → 官方缓解方案 → 业务层规避”这一整条闭环。

知识点

1. 信号安全性：C 代码若正在持有一把非递归锁、写半条指令、调 malloc，突然重入 Go 信号处理函数，极易死锁或破坏堆结构。
2. TSAN/ASAN 误报：C 侧若开线程检查器，Go 的 SIGURG 会被当成“外部未知信号”，报告 data race 或 lock-order 违规。
3. C 库重启性：部分国产 SDK（如某些音视频编解码库）在信号处理里自己再 raise 一次 SIGURG，导致无限递归，直接把进程打挂。
4. 性能回退：高并发 cgo 场景（网关调用国密 SO）下，频繁信号打断造成 syscall 重试 与 锁竞争，CPU 利用率反而上升 5%–10%。
5. 调试困难：delve、perf 等工具会把 SIGURG 当成用户信号，断点停不下来，线上火焰图失真。
6. 官方缓解：Go 1.20 起，运行时把 cgo 临界区 标记为 M 不可抢占，信号改为“延迟到 C 返回后再处理”，但临界区时间片不可控，仍可能长尾。

答案

“Go 1.19 的全局异步抢占对 cgo 的主要副作用体现在 信号安全、死锁、TSAN 误报、性能回退 四个方面。

1. 当 M 正在执行 C 函数时，SIGURG 仍会到达，C 代码若持锁或做内存分配，重入 Go 信号处理函数后可能死锁或踩内存。
2. 国内很多 SO 库用 TSAN/ASAN 做门禁，Go 的 SIGURG 被当成外来信号，流水线直接报 data race，导致合入失败。
3. 高并发网关场景下，每次 cgo call 平均 2–3 µs，但抢占信号带来额外 syscall 重试，CPU 上涨 5% 以上，尾延迟 P99 增加 10%。
4. 官方在 1.20 做了缓解：进入 cgo 后把 M 设为 non-preemptible，信号延迟到 C 返回；但临界区过长仍会被手工栈扫描抢占，业务层必须把可能阻塞的 C 调用拆小，或者升级 Go 版本并打开 GODEBUG=asyncpreemptoff=1 做兜底开关。”

拓展思考

1. 如果业务必须长时间阻塞在 C 侧（例如调用国产加密卡的 pci 驱动 ioctl），可以把这段逻辑放到 单独线程（pthread_create 后通过 pipe 与 Go 通信），彻底避开 Go 的调度信号。
2. 国内云厂商的 K8s 1.24+ 基线镜像 已默认 Go 1.20，但存量 sidecar 仍用 1.19，灰度时务必观察 sched_preemption_cgo_total 指标，一旦出现非零增长就回退。
3. 未来 Go 准备引入 “cooperative yield on cgo” 机制：C 代码主动在循环里插入 runtime.Gosched() 标记点，实现“可抢占的 cgo”，面试时可以作为技术前瞻与面试官探讨。