goroutine 是 go 运行时 gmp 模型管理的用户态并发单元，创建开销仅 20–50 ns（栈 2kb），远低于 os 线程的 1–5μs（栈 2mb），支持单机十万级并发；其非阻塞调度依赖 runtime 封装系统调用并解耦 m，通信首选 channel 而非锁，避免竞态与死锁。
Go 的 goroutine 不是线程，也不是“轻量级线程”的简单替代；它是运行时调度器（GMP）管理下的用户态并发单元，和操作系统线程存在本质的调度关系、资源模型与通信范式差异。
goroutine 和 OS 线程的创建开销差多少？
创建一个 goroutine 平均耗时约 20–50 ns，初始栈仅 2KB（可动态扩缩）；而调用 pthread_create 创建一个 OS 线程，通常需 1–5μs，且默认栈空间为 2MB（Linux 下常见）。这意味着：你可以在单机上安全启动 100,000+ 个 goroutine，但超过 10,000 个 OS 线程就极易触发 ENOMEM 或调度抖动。
- 实操建议：别用
go f()启动无限循环且无退出逻辑的 goroutine，哪怕它很“轻”——泄漏的 goroutine 会持续占用堆内存（如闭包捕获大对象） - 验证方式：运行时可通过
runtime.NumGoroutine()观察数量，配合pprof查看 goroutine stack trace - 注意：
GOMAXPROCS控制的是“可并行执行的 OS 线程数”，不是 goroutine 数量上限；它影响的是并行度，而非并发能力
为什么 goroutine 不会因系统调用阻塞整个线程？
Go 运行时对多数阻塞系统调用（如文件 I/O、网络读写、time.Sleep）做了封装，当某个 goroutine 调用这些函数时，运行时会将其从当前 OS 线程（M）上剥离，并把该线程交还给其他 goroutine 使用，同时将阻塞的 goroutine 挂起在 netpoller 或 timer heap 上。这依赖于 Go 的 non-blocking I/O + epoll/kqueue/IOCP 底层支持。
- 常见错误现象：用
os.Open打开一个 NFS 挂载点上的慢设备文件，若未设超时，可能卡住整个 M —— 因为部分 syscall 无法被异步化（如某些磁盘 I/O） - 规避方法：优先使用
net/http、database/sql等标准库封装好的带 context 支持的 API；自定义阻塞操作务必包裹在runtime.LockOSThread()+ 单独 goroutine 中隔离 - 关键区别：Java 线程遇到
read()阻塞，整个线程（含 JVM 栈）直接让出 CPU 给 OS 调度器；而 Go 是在用户态完成“解耦-重调度”，无需陷入内核
channel 通信 vs 共享内存 + 锁，到底省了什么？
channel 不是“语法糖”，它是 Go 运行时内置的同步原语，底层由环形缓冲区 + g 队列 + 自旋/休眠状态机实现。它强制你显式声明数据流向（chan int）、所有权转移（发送即移交）和同步点（阻塞收发），天然规避了竞态、死锁（部分）、忘记 unlock 等问题。
- 典型坑：用
sync.Mutex保护 map 时，忘了加defer mu.Unlock()或 panic 后没 recover，导致锁永远不释放；而ch 天然具备原子性与上下文感知 - 性能提示：无缓冲 channel 的 send/receive 是完全同步的（即配对 goroutine 直接交接），比 mutex + condvar 更快；有缓冲 channel 在缓冲未满/非空时可零拷贝快速通行
- 慎用场景：高频、小数据、确定无等待的跨 goroutine 传值，可考虑
unsafe.Pointer+atomic.Store/Load，但 channel 仍是绝大多数场景下最安全、最易推理的选择
GMP 模型里，P 到底管什么？
P（Processor）是 Go 调度器的核心抽象，它代表“可运行 goroutine 的逻辑上下文”，每个 P 绑定一个本地运行队列（runq）、一个全局队列（globrunq）、以及 netpoller 和 timer 管理权。它不对应 CPU 核心，但数量默认等于 GOMAXPROCS（即最大并行线程数）。
- 关键事实：一个空闲的
P可以被任意空闲M（OS 线程）获取来执行 goroutine；当M遇到系统调用阻塞时，它会尝试将绑定的P转交给其他M，自己进入休眠 —— 这就是“M 可以远多于 P，P 可以复用 M”的基础 - 调试线索：若观察到
runtime.GC频繁或schedtrace显示大量P处于_Pidle状态但M很少，说明 goroutine 大量阻塞在非可调度操作（如 C 代码、syscall.Syscall）上 - 不要手动调
runtime.GOMAXPROCS(n)来“提升性能”：现代 Go 默认已设为 CPU 核心数；盲目调高只会增加 P 切换开销，调低则浪费并行能力
真正难的不是理解 GMP 三字母，而是判断什么时候该让 goroutine 等待 channel，什么时候该用 context.WithTimeout 主动取消，以及——当 pprof 显示 90% 时间花在 runtime.futex 上时，你得意识到那根本不是 goroutine 的问题，而是你在用 sync.RWMutex 锁住了整个服务请求链路。
