Go 面试 2026 版：泛型、GMP 模型与并发编程高频考点

泛型：理解类型约束，而不只是会用语法

面试里经常有人能默写泛型语法，但一到场景题就露馅。比如让你设计一个支持任意类型的栈，早几年大家习惯用interface{}实现，现在更希望看到你写类型参数。两者最重要的差别不是性能，而是类型安全。interface{}把类型检查推迟到运行时，泛型则把类型检查提前到编译期，代价是约束和代码复杂度。

一个常见的误区是，泛型能提升运行性能。实际上，泛型代码在实例化后和手写版本基本等价，运行性能并没有魔法提升，编译器编译时间和二进制体积反而可能增加。泛型适合用在通用容器、工具函数、ORM的复杂类型推导等场景，但不适合因为“看起来高级”就把所有业务代码改造成泛型。

下面是一个具备去重能力的泛型函数，它用comparable约束保证类型可以比较：

func Dedup[T comparable](items []T) []T {
    seen := make(map[T]bool)
    result := make([]T, 0, len(items))
    for _, v := range items {
        if !seen[v] {
            seen[v] = true
            result = append(result, v)
        }
    }
    return result
}

因为约束是comparable，所以map[T]bool可以正常工作。如果你去掉约束，编译器会直接报错，这就是泛型把错误提前到编译期的直观体验。

解决这个问题，通常可以从工具库开始尝试，比如专门处理集合和切片，而不是一上来就重构核心API。当然，泛型必然会带来约束设计的成本，尤其是当约束与接口的方法集混在一起时，理解起来会有点绕。

如果下面几点都满足，泛型确实是值得考虑的选择：

有一个算法或容器需要服务于多种具体类型；
调用方可以明确知道自己的类型，不需要运行时多态；
你能承受编译期的类型推导复杂度，并愿意维护约束代码。

维度	泛型	interface{}
类型安全	编译期确定	运行时断言
代码复用	强类型复用	需要类型断言
性能特点	无装箱，接近手写	接口分派有开销
适用场景	容器、算法、中间件	运行时多态、未知类型

GMP 模型：面试问调度，其实在问你对并发下半场的理解

三个字母分别代表Goroutine、Machine、Processor。G是用户态协程，M是真正执行代码的操作系统线程，P是逻辑处理器，它控制着本地运行队列，G只有被分配到某个P上才会被M执行。为什么中间非要放一层P？答案是为了减少全局锁竞争，同时让调度有更细的粒度。如果没有P，所有G的调度都需要走一个全局队列，并发量一大，锁竞争就会变成瓶颈。

调度器的大致循环并不复杂：新G优先放到当前P的本地队列，本地队列满了就放到全局队列。P空闲时会先从本地队列取G，取不到就去全局队列拿一批，再没有就去其他P偷一半G。下面是简化后的优先级顺序，面试时把这个说清楚比背概念有用：

P的调度循环（简化）：
1. 从本地队列取G
2. 本地队列空，则从全局队列取一批
3. 全局队列也空，则从其他P偷取一半G
4. 都没有，则让M休眠或自旋

这里有一个容易踩坑的认知：goroutine是不是完全协作式调度？Go 1.14 之前更多依赖栈扫描和GC触发协作点，1.14 之后引入了基于信号的异步抢占，加上原有的协作式机制，所以现在是抢占式与协作式并存。长时间CPU密集型任务如果没有主动让出时间片，异步抢占会把G打断，避免整个P被一个G占死。

另一个常见误区是，GOMAXPROCS越大，程序越快。它控制的是“可并行执行的线程数”，并不等于“吞吐上限”。当它超过CPU核数后，额外的P可能会让M看起来更多，线程切换和缓存竞争反而变大，在容器环境里尤其明显，容易忽略cgroup限制导致P设置过多。

角色	对应实体	主要职责
G	Goroutine	持有栈和上下文
M	OS线程	实际执行Go代码
P	逻辑处理器	运行队列与调度G

如果你在生产环境遇到CPU跑满但吞吐完全上不去的情况，可以用go tool pprof或go tool trace看调度耗时。很多所谓“并发不生效”的问题，最后都落在锁竞争、系统调用阻塞或者P的调度不均匀上。

遇到调度相关的问题，通常按这几个层面排查：

用pprof看goroutine数量和调用栈，判断是否大量G卡在某个等待点；
用trace看P和M的分布，确认是否存在偷取和阻塞热点；
结合runtime.SetMutexProfileFraction定位锁竞争。

并发编程：channel、锁、原子操作不只是三选一

高频考点集中在同步机制的正确使用上，而不是列出多少并发模式。先说三个最容易被问倒的边界情况：向已经关闭的channel发送数据会panic，重复关闭channel也会panic；sync.WaitGroup的Add必须发生在Wait并发之前，如果Add放在子goroutine里，主goroutine可能提前退出；map并发读写会触发fatal error，必须用锁或sync.Map兜底。

选型上，锁保护共享状态，channel传递数据所有权，原子操作处理简单计数器和标志位。没有绝对好坏，只有合适与不合适。channel的通信语义清晰，但多人同时维护一个全局channel时，很容易出现阻塞和超时问题；锁虽然看起来笨重，但在低竞争场景下往往更直接。

一个典型的worker pool写法如下，它用带缓冲的channel控制任务分发，用WaitGroup等待所有worker结束：

var wg sync.WaitGroup
jobs := make(chan int, 10)
for i := 0; i < 3; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        for j := range jobs {
            process(j)
        }
    }()
}
for n := 0; n < 20; n++ {
    jobs <- n
}
close(jobs)
wg.Wait()

这里close(jobs)是必要的，否则worker会永远等待接收。关闭channel的职责通常由生产者负责，多生产者时则需要用sync.Once或专门的关闭协调逻辑。

使用原子操作时要注意，它只解决单个内存变量的并发读写，如果状态由多个变量共同构成，原子的单个变量操作无法保证整体一致性，仍然需要锁。

同步方式	适用场景	常见代价
Mutex/RWMutex	保护共享结构体或复杂状态	锁竞争与性能抖动
atomic	简单计数器、状态标志	只能原子操作单个变量
channel	数据传递、任务分发、信号通知	阻塞、关闭与数据流复杂度