go协程（goroutine）是用户态轻量级任务，不直接绑定cpu核心；其调度依赖g-p-m模型：g为协程、p为逻辑处理器（默认数量等于cpu逻辑核数，由gomaxprocs控制）、m为os线程；p负责维护本地运行队列，m实际执行代码，p与m可动态解绑与重绑定以应对系统调用阻塞，从而提升并发效率。
goroutine不是线程，也不直接绑定CPU核心
Go程序启动时默认设置 GOMAXPROCS 为机器可用逻辑CPU数，但这只是P（Processor）的数量上限，并不等于OS线程数，更不等于CPU核心数。P是调度器的逻辑资源单元，用来维护本地运行队列（LRQ），它本身不执行代码——真正干活的是M（Machine），即OS线程。一个P可以绑定多个M（比如发生阻塞系统调用时），一个M也可以在不同时间绑定不同P。
常见误解是“GOMAXPROCS=4 就只用4个核”，其实只要M没被阻塞，运行时会尽量让多个M同时在不同核心上跑；而一旦某个M陷入系统调用（如read()、open()），它会自动解绑P，由其他空闲M接替该P继续调度G，避免P闲置。
长时间纯计算循环仍可能阻塞调度器（尤其在1.13及更早版本）
虽然Go 1.14+引入了异步抢占（基于SIGURG信号 + 循环头部插入runtime.preemptM检查），但并非所有循环都能被及时打断。以下情况仍存在调度延迟风险：
- 极短循环体（如
for i := 0; i ）可能因未触发安全点而跳过抢占检查 - 内联函数或编译器优化后消除函数调用边界，导致协作点消失
- 使用
//go:noinline标记但未在循环中显式插入runtime.Gosched()
实操建议：对已知会长时间占用CPU的计算逻辑（如图像处理、数值积分），主动在循环体内每千次迭代插入一次runtime.Gosched()，或改用time.Sleep(0)——后者本质也是触发一次调度让渡。
goroutine泄漏的典型表现和快速定位方式
goroutine数量持续增长却不下降，是服务内存缓慢上涨、响应变慢的首要嫌疑。关键不是“有多少goroutine”，而是“哪些没退出”。常用诊断方式：
- 用
runtime.NumGoroutine()定期打点，结合Prometheus暴露为指标 - 当怀疑泄漏时，立即用
curl http://localhost:6060/debug/pprof/goroutine?debug=2（需启用net/http/pprof）查看完整栈，重点关注卡在chan receive、select、time.Sleep或net.Conn.Read的goroutine - 注意
debug=2输出里带created by字段的行——它指向goroutine的启动位置，比堆栈顶部更有定位价值
常见泄漏模式：channel未关闭导致接收方永久阻塞；timer未Stop()且未drain；HTTP handler中启goroutine但没做超时控制或上下文取消监听。
阻塞系统调用不会卡死整个P，但会消耗M资源
当goroutine执行阻塞式系统调用（如os.Open、net.Conn.Write），当前M会脱离P并进入系统调用等待状态。此时P会尝试唤醒或创建新M来继续执行其他就绪G。这机制保证了P不被拖住，但M本身仍在OS层面占用线程资源。
问题在于：M总数有硬上限（默认10000，由runtime.SetMaxThreads控制）。若大量goroutine同时发起阻塞IO，M数可能迅速逼近上限，后续阻塞调用会失败并报runtime: failed to create new OS thread错误。
规避方法：
- 优先使用非阻塞IO封装（如
net/http默认走netpoller，不占M） - 对必须用阻塞IO的场景（如某些数据库驱动），限制并发数（用
semaphore或带缓冲channel控制goroutine总量） - 避免在goroutine里反复
fork/exec子进程——每次都会绑定一个新M且不易回收
真正容易被忽略的是cgo调用：任何C函数都默认使当前M进入locked to thread状态，且无法被调度器复用。这类M既不参与goroutine调度，也不受GOMAXPROCS约束，却计入SetMaxThreads总配额。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
