必须配对使用lockosthread和unlockosthread，仅当c库强依赖tls或同线程创建/销毁资源时才需绑定，如opengl、alsa、windows gui、老版openssl；滥用会导致线程泄漏、cpu利用率骤降、调度失控。
绝大多数 Go 项目根本不需要调用 runtime.LockOSThread——它不是性能优化手段，而是为极少数 C 库线程约束兜底的“急救开关”。
哪些 C 库调用必须配对使用 LockOSThread 和 UnlockOSThread
只有当 C 函数内部强依赖线程局部存储（TLS）或要求“同一线程创建/销毁资源”时才必须绑定。典型例子包括：
-
OpenGL上下文（glXMakeCurrent、wglMakeCurrent等） -
ALSA音频句柄（snd_pcm_open后所有操作需同线程） - Windows GUI API（
CreateWindowEx+GetMessage循环） - 老版本
OpenSSL的RAND_bytes（依赖pthread_setspecific）
反例：sqlite3、zlib、libcurl（现代版本）、libpng——这些库本身线程安全，加锁反而引入调度瓶颈。
LockOSThread 后忘记 UnlockOSThread 的真实后果
这不是“可能出问题”，而是必然导致线程泄漏：
- 该 OS 线程被永久独占，无法参与 goroutine 调度，
runtime.NumGoroutine()可能正常，但 CPU 利用率骤降 - 在 HTTP 服务中，每个请求都锁一次线程 → 快速耗尽线程池 →
accept: too many open files或runtime: cannot create new OS thread - panic 发生在
LockOSThread()之后、UnlockOSThread()之前 → defer 不执行 → 绑定永不释放
正确写法只有一种：runtime.LockOSThread() 紧跟 defer runtime.UnlockOSThread()，且不能跨函数边界（A 函数 lock，B 函数 unlock 是无效的）。
CGO 调用本身不会自动触发线程绑定
这是最常被误解的一点：import "C" 或任何 C.xxx() 调用，都不会隐式调用 LockOSThread。
- CGO 调用期间，Go 运行时会临时暂停当前 M（OS 线程）的 goroutine 调度，但结束后立即恢复——这和线程绑定无关
- 如果 C 函数阻塞超过 20ms（默认），Go 会启用新 M 继续跑其他 goroutine，原 M 醒来后仍归还给 P
- 真正需要绑定的，是那些 C 库内部状态与
pthread_self()强耦合的情况，而非“只要调 C 就要锁”
验证方法：在 CGO 调用前后打印 runtime.LockOSThread 返回值（实际无返回值），或用 strace -f -e trace=clone,exit_group 观察线程数是否异常增长。
最容易被忽略的点：LockOSThread 绑定的是 goroutine 生命周期，不是函数作用域。如果 goroutine 在 locked 状态下调用了 time.Sleep 或 net.Conn.Read，绑定依然有效；但如果它进入 syscall 且该 syscall 被标记为“非托管阻塞”（如自定义封装的 syscall.Syscall），运行时可能偷偷换线程——此时绑定失效，且无任何错误提示。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
