Goroutine是Go运行时管理的轻量级用户态协程，初始栈仅2KB、按需增长，M:N调度通过GMP模型实现高效并发，推荐用Channel通信而非共享内存。
Go 的并发模型核心是 Goroutine，它不是操作系统线程（Thread），而是一种轻量级、由 Go 运行时（runtime）管理的用户态协程。理解 Goroutine 与 OS Thread 的本质区别，是回答并发模型面试题的关键。
Goroutine 的轻量性体现在哪里
Goroutine 启动开销极小：初始栈仅 2KB，按需动态增长（最大可达几 MB）；创建、销毁、切换均由 Go runtime 在用户态完成，不触发系统调用。相比之下，OS Thread 栈通常固定为 1–2MB（Linux 默认 8MB），创建/销毁需内核参与，上下文切换成本高。
- 10 万个 Goroutine 可常驻内存，总栈空间可能仅几十 MB
- 10 万个 OS Thread 几乎必然导致 OOM 或调度崩溃
- Goroutine 切换不涉及 CPU 寄存器保存/恢复和内核态切换，延迟在纳秒级
调度机制完全不同
Goroutine 使用 M:N 调度模型（M 个 Goroutine 映射到 N 个 OS Thread），由 Go runtime 的 GMP 模型调度：G（Goroutine）、M（Machine，即 OS Thread）、P（Processor，逻辑处理器，绑定 M 并管理本地运行队列）。P 的数量默认等于 CPU 核心数（可通过 GOMAXPROCS 修改），实现工作窃取（work-stealing）负载均衡。
- 一个阻塞的 Goroutine（如系统调用、网络 I/O）不会阻塞 M，runtime 会将该 M 与 P 解绑，另起一个 M 继续执行其他 G
- 而 OS Thread 阻塞时，整个线程挂起，无法执行其他任务
- Go runtime 自动处理 I/O 多路复用（如 epoll/kqueue），使网络操作几乎不阻塞 M
共享内存 vs. 通信方式的设计哲学
Goroutine 之间**推荐通过 Channel 通信，而非共享内存加锁**。这不是语法限制，而是 Go 的并发原语设计导向：Channel 提供同步、解耦、背压能力；sync.Mutex 等仍可用，但易引发竞态、死锁或过度同步。
立即学习“go语言免费学习笔记（深入）”；
-
go func() { ch <- data }()是典型非阻塞发送（若缓冲区满则 goroutine 挂起，不忙等） - Channel 底层由 runtime 管理，读写操作自动触发 goroutine 唤醒/休眠，无需显式条件变量
- Go race detector 能静态+动态检测数据竞争，强化“不要通过共享内存来通信”的实践
实际编码中如何体现差异
写一个 HTTP 服务就能看出区别：用 net/http 启一个服务，每请求启一个 Goroutine —— 即便并发 10 万连接，资源占用可控；若用传统 Java/Python 每连接启一个线程，很快耗尽内存或线程数上限。
- 启动 Goroutine：用
go f()，无参数传递开销（闭包捕获变量） - 停止 Goroutine：没有强制终止 API（
goexit仅退出当前 goroutine），靠 channel 控制生命周期 - 调试：可用
pprof查看 Goroutine 数量、栈、阻塞点，runtime.NumGoroutine()获取实时数量
