runtime.lockosthread 仅在线程局部状态（tls）依赖且无法改写时必须使用，如opengl上下文、老版openssl rand_*函数等；滥用会导致goroutine饥饿、死锁；必须配对使用defer unlockosthread，cgo调用本身不自动绑定线程。
CGO 调用中，runtime.LockOSThread 不是“保命符”，而是“双刃剑”——它只在极少数明确需要线程绑定的场景下才该启用，滥用反而导致 goroutine 饥饿、死锁或调度失控。
什么时候必须用 runtime.LockOSThread？
仅当 CGO 函数依赖**线程局部状态**（TLS）且无法改写时才需锁定。典型场景包括：
-
dlopen/dlsym加载的 C 库要求调用者始终在同一线程（如某些 OpenGL 上下文、老版本 OpenSSL 的 RAND_* 系列函数） - C 侧使用
pthread_setspecific存储关键句柄，且未提供跨线程传递机制 - 调用 X11 或 ALSA 等传统 Unix 图形/音频 API，其内部状态与
pthread_self()强绑定
注意：sqlite3、zlib、现代 libcurl 等绝大多数 C 库本身是线程安全的，不需要也不应该加锁。
LockOSThread 后忘记 UnlockOSThread 的后果
这是最常踩的坑：goroutine 锁定 OS 线程后未释放，导致该线程永远被独占，后续 goroutine 无法调度到该线程上，表现为 CPU 利用率异常偏低 + 并发吞吐骤降。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
runtime.LockOSThread()放在函数开头，但中间 panic 或 return 早于runtime.UnlockOSThread() - 正确做法：必须用
defer runtime.UnlockOSThread()，且确保它在LockOSThread之后立即注册 - 特别注意：CGO 调用若跨多个函数，锁定和解锁必须严格配对在同一 goroutine 栈帧内；不能 A 函数锁、B 函数解
示例：
func callThreadLocalC() {
runtime.LockOSThread()
defer runtime.UnlockOSThread() // 必须紧随 Lock 之后，不可省略
C.do_something_that_needs_tls()
}CGO 调用本身是否自动触发线程绑定？
不会。import "C" 本身不引发任何线程绑定行为。Go 运行时对 CGO 调用的处理是：临时将当前 M（OS 线程）交给 P（逻辑处理器），执行 C 代码期间该 M 暂停调度 goroutine，但结束后自动恢复——这和 LockOSThread 完全无关。
- 真正影响调度的是 C 函数是否阻塞：若 C 函数长期阻塞（如
sleep(10)），Go 会启用新 M 继续跑其他 goroutine，原 M 醒来后仍归还给 P -
LockOSThread是主动“声明所有权”，而 CGO 阻塞只是运行时被动应对，二者目的、时机、开销都不同 - 混淆这两者，容易误以为“只要调了 C 就要锁线程”，结果在 HTTP server 中每个请求都锁线程，瞬间耗尽系统线程数
真正的难点不在语法，而在判断 C 库是否真的需要线程绑定——它往往藏在 C 头文件注释里、旧版文档角落，或干脆没有说明。动手前，先查清目标 C 函数是否读写 errno、是否调用 pthread_getspecific、是否显式要求“same thread”。不确定，就别锁。
