第2章 Go语言基础高频面试题：并发模型、GMP调度、内存模型、defer/panic/recover
本章聚焦四大高频考点：GMP调度模型、Go内存模型与happens-before、defer/panic/recover机制。建议先理解调度循环与协作式抢占，再掌握内存模型的可见性保证，最后用defer+panic实战场景检验综合能力。
核心知识点速览
| 主题 | 关键点 |
|---|---|
| GMP调度 | P本地队列 → 全局队列 → 工作窃取 → 系统调用抢占 |
| 内存模型 | happens-before、channel/atomic/CAS保证有序性与可见性 |
| defer/panic/recover | defer栈执行、panic跳跃defer、recover仅能捕获一次 |
面试问答卡片
Q1: 请简述Go的GMP调度模型及其优势。
面试官考察点
- 是否理解P在M和G之间的桥梁作用
- 能否解释工作窃取（work stealing）和协作式抢占
- 与早期GM模型对比的改进点
回答框架
- GM模型问题：全局锁、多M争抢G导致性能瓶颈
- 引入P：每个P有本地G队列，减少锁竞争
- 调度循环：先找本地队列 → 全局队列 → 其他P窃取
- 协作式抢占：函数调用时检查抢占标记，避免长时间占用
- 系统调用处理：阻塞M的P让出给其他M继续执行
简短示例回答：GMP通过P将G与M解耦，每个P拥有本地队列，优先调度本地G，减少全局锁竞争。当本地队列为空时从全局或其他P窃取任务。系统调用阻塞时，P与M分离并绑定新M，提高并发利用率。
可能追问
- GOMAXPROCS如何影响调度？
- 为什么说Go的抢占是“协作式”而不是“抢占式”？
- 如何处理syscall中长时间阻塞的M？
避坑提醒：不要将GMP与操作系统的线程调度混为一谈；说明P的数量由GOMAXPROCS决定而非CPU核心数。
Q2: 解释Go内存模型中的happens-before原则，并举例说明。
面试官考察点
- 是否理解happens-before与数据竞争的关系
- 能否说出channel、sync.Mutex、atomic操作保证顺序的方式
- 能否指出无同步的并发读取为何不安全
回答框架
- 定义：如果操作A happens-before B，则A对共享变量的修改对B可见
- 保证机制：channel发送/接收、Mutex.Lock/Unlock、atomic.Store/Load
- 常见陷阱：单独使用atomic.Load/Store但未配合happens-before则无法保证顺序
简短示例回答：例如：
go启动goroutine前写入的变量，在goroutine中无法保证可见性，必须通过channel或mutex同步。happens-before确保channel发送在接收之前完成，从而避免数据竞争。
可能追问
- sync.WaitGroup是否保证happens-before？
- 只使用atomic.AddInt64能否替代Mutex？为什么？
- 谈谈Go的memory reorder与编译器优化
避坑提醒：不要误认为ch <- v之后立即<- ch就能保证顺序；channel本身已保证happens-before，但多个goroutine同时操作同一channel仍需注意。
Q3: defer、panic、recover的底层机制及常见陷阱。
面试官考察点
- 是否理解defer语句在函数返回前以LIFO顺序执行
- 能否说明panic发生后defer链仍会执行
- recover只能在defer中生效的原因
- 能否指出defer中修改返回值等陷阱
回答框架
- defer：注册到goroutine的defer栈，return时逆序执行
- panic：停止当前函数，逐层沿调用栈执行defer，若未recover则崩溃
- recover：必须在defer中调用，返回panic值并恢复控制，但循环中的panic无法被外层recover
简短示例回答：defer以栈方式存储，return时逆序执行。panic会立即终止当前函数，但所有已注册的defer会依次执行。若defer内调用recover，则捕获panic值并继续正常执行。注意recover只能使用一次，且不能在非defer函数中生效。
可能追问
- 多次panic时defer的执行顺序？
- defer中修改命名的返回值会发生什么？
- recover后如何获取原始panic信息？
避坑提醒：不要在defer外调用recover（无效）；不要认为panic后recover可以捕获所有子goroutine的panic（不同goroutine需要各自defer/recover）。