goroutine 是 Go 运行时管理的用户态并发单元，非轻量级线程；其调度在用户态完成（20–50 ns），阻塞时不挂起 OS 线程；channel 强制 CSP 模型，避免共享内存与锁；GMP 模型中 P、M、G 协同实现高效调度；goroutine 适合 I/O 密集型任务，慎用于纯计算密集型场景，禁用无节制循环启动。
goroutine 不是线程，也不是“轻量级线程”的同义词
这是最常被误解的一点：很多人说“goroutine 是轻量级线程”，但 Go 官方文档和 runtime 设计明确否定这种类比。goroutine 是由 Go 运行时（runtime）完全管理的用户态并发单元，它不对应任何 OS 线程，也不受内核调度器控制。它的生命周期、栈伸缩、阻塞唤醒全部在用户空间完成。
关键区别在于调度层级：
- OS 线程（如 pthread）由内核调度，每次切换需陷入内核，开销在 1–5μs 量级；
- goroutine 切换由 Go 调度器（GMP 模型）在用户态完成，开销仅 20–50 ns；
- 一个 goroutine 阻塞（比如
read网络 socket）时，runtime 会自动将它从当前 M（OS 线程）剥离，并唤醒另一个 G，而无需挂起整个线程。
这意味着你写 go http.HandleFunc(...) 启动十万连接，底层可能只用了 4 个 OS 线程（取决于 GOMAXPROCS），但每个连接都拥有独立执行上下文——这不是“复用线程”，而是“解耦调度”。
channel 通信强制替代共享内存 + 锁
Go 的并发模型基于 CSP（Communicating Sequential Processes），核心信条是：“Don’t communicate by sharing memory; share memory by communicating.” 这不是风格偏好，而是语言机制层面的约束。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：sync.Mutex 滥用、竞态检测器（go run -race）报出 data race、死锁在 select 中卡住——往往源于试图把 Java/C++ 的线程思维平移进 Go。
- channel 是类型安全、可缓冲/无缓冲、可关闭的一等公民，创建即带同步语义；
- 向无缓冲 channel 发送会阻塞，直到有 goroutine 在另一端接收——天然形成协作节奏；
- 用
for range ch或select处理多路 channel，比手写条件变量 + 锁清晰得多； - 切忌用 channel 传大结构体指针再加锁访问字段——这等于绕过 CSP，退回共享内存老路。
示例反模式：
var mu sync.Mutex→ 正确做法是用 channel 把 “写 x” 和 “读 x” 封装成消息。
var data map[string]int
go func() { mu.Lock(); data["x"] = 1; mu.Unlock() }()
go func() { mu.Lock(); fmt.Println(data["x"]); mu.Unlock() }()
GMP 调度模型里 P、M、G 的实际影响
理解 GMP 不是为了背概念，而是为了调优和排障。例如线上服务 CPU 使用率低但延迟高，很可能不是代码慢，而是 G 被卡在系统调用或 GC 上，而 M 数不足导致就绪 G 排队。
-
P（Processor）数量默认 = CPU 核心数，可通过runtime.GOMAXPROCS(n)调整；设太小会压不住并发，设太大则增加调度抖动； -
M（Machine）是 OS 线程，当 G 遇到阻塞系统调用（如open、accept）时，M 会被分离，新 M 启动继续跑其他 G； -
G（Goroutine）栈初始仅 2KB，按需增长收缩；但若频繁分配 >2KB 局部变量（如大数组），会导致栈拷贝开销上升； - 注意：
net/http默认为每个请求启一个 goroutine，但若 handler 里做同步磁盘 I/O，会拖慢整个 M——应改用异步 I/O 或协程池限流。
什么时候该用 goroutine，什么时候该避免
goroutine 极轻，但不等于“无成本”。滥用仍会触发调度器压力、GC 压力、内存碎片甚至栈溢出。
- 适合：I/O 密集型任务（HTTP 请求、数据库查询、文件读写）、状态独立的事件处理（WebSocket 连接、MQ 消费）；
- 慎用：纯计算密集型且无法分片的任务（如单次大矩阵乘法）——应交由
runtime.LockOSThread()绑定 M，或改用 worker pool 控制并发数； - 禁用：在循环中无节制启动 goroutine，尤其未配
sync.WaitGroup或 channel 控制生命周期，极易泄漏； - 典型坑：
for i := range items { go f(i) }→ 所有 goroutine 共享同一个i变量，结果全拿到最后一个值；正确写法是go f(items[i])或显式传参。
真正难的不是启动 goroutine，而是定义它的边界：何时开始、何时结束、如何传递错误、谁负责回收资源。这些必须在设计阶段就嵌入 channel 结构或 context 生命周期里，而不是靠事后加日志或 pprof 猜。
