Golang 核心面试题¶

以对话形式回答，模拟真实面试场景

1. make 和 new 的区别？¶

面试官：能说说 make 和 new 的区别吗？

回答：好的，这是一个很基础但很重要的问题。

首先说 new，new 是一个内置函数，它可以为任何类型分配内存，返回的是指向该类型零值的指针。比如说 new(int) 会返回一个 *int 类型的指针，指向的值是 0。

而 make 就不一样了，它只能用于三种引用类型：slice、map 和 channel。make 返回的是类型本身，不是指针，而且它会对这些类型进行初始化，让它们可以直接使用。

举个例子，如果我用 new([]int)，得到的是一个 *[]int 类型的指针，指向一个 nil 的切片，我还不能直接往里面添加元素。但如果用 make([]int, 5)，我直接得到一个长度为 5 的切片，可以立即使用。

面试官：那你在实际开发中更倾向于用哪个？

回答：实际开发中，make 用得更多一些。因为我们经常需要创建 slice、map 这些集合类型，而 new 主要在需要指针类型的场景下使用，比如在结构体字段需要指针的时候。

2. 了解过golang的内存管理吗？¶

面试官：Go 的内存管理你了解吗？能简单说说吗？

回答：了解的，Go 的内存管理设计得挺精巧的，主要借鉴了 TCMalloc 的思想。

它有三个核心组件：首先是每个 P（逻辑处理器）都有自己的 mcache，这样可以减少锁竞争；然后是全局的 mcentral，负责管理不同大小的内存块；最后是 mheap，管理大块内存。

在分配策略上，Go 做了分层处理：小于 32KB 的对象通过 mcache 快速分配；大于 32KB 的大对象直接从 heap 分配；还有个特殊优化，就是小于 16 字节的微小对象会多个共享一个内存块，这样可以减少内存碎片。

面试官：那垃圾回收呢？

回答：Go 使用的是三色标记算法配合写屏障技术。最大的优势是可以并发标记，大大减少了 STW（Stop The World）的时间。从 Go 1.14 开始还引入了分代假设优化，进一步提升了 GC 性能。

我在实际项目中也遇到过 GC 压力比较大的情况，通常会通过对象池化、减少小对象分配这些方式来优化。

3. 调用函数传入结构体时，应该传值还是指针？说出理由？¶

面试官：在 Go 中，调用函数传结构体参数时，你是传值还是传指针？为什么？

回答：这个问题我在实际开发中经常遇到。一般情况下，我更倾向于传指针。

主要有几个考虑：首先是性能问题，如果结构体比较大，传值的话会发生完整的内存拷贝，开销比较大；而传指针只需要拷贝8个字节的地址。

其次是功能需求，如果函数需要修改结构体的内容，那必须传指针，传值的话修改的只是副本。

还有就是一致性考虑，Go 标准库中的方法大多都是指针接收者，保持一致的风格比较好。

面试官：什么时候会考虑传值呢？

回答：传值主要是在结构体特别小的情况下，比如只有两三个基本类型字段，而且不需要修改原对象。像坐标点这种小结构体，传值反而可能更高效，因为避免了指针解引用的开销。

不过实际项目中，为了保持代码风格的一致性，我通常还是会统一使用指针。

4. 线程有几种模型？Goroutine的原理了解过吗，讲一下实现和优势？¶

面试官：能说说线程模型有哪几种吗？Go 的 Goroutine 是怎么实现的？

回答：好的，线程模型主要有三种：

N:1 模型，就是多个用户线程映射到一个内核线程，这种模型的问题是无法利用多核；1:1 模型，用户线程和内核线程一一对应，这种开销比较大；还有 M:N 模型，M 个用户线程映射到 N 个内核线程，这是目前比较主流的方案。

Go 的 Goroutine 就采用了 M:N 模型，通过 GMP 模型来实现。G 就是 Goroutine，是用户态的协程；M 是 Machine，代表系统线程；P 是 Processor，逻辑处理器，每个 P 都有自己的 Goroutine 运行队列。

面试官：那 Goroutine 相比传统线程有什么优势？

回答：优势还是很明显的。首先是轻量级，一个 Goroutine 初始栈只有 2KB，而系统线程通常需要 8MB，所以可以轻松创建百万级的 Goroutine。

其次是切换成本低，Goroutine 的切换完全在用户态进行，不需要系统调用，切换速度非常快。

还有就是调度智能，Go 运行时实现了 work-stealing 算法，当一个 P 的队列空了，会从其他 P 那里"偷"任务来执行，实现了很好的负载均衡。

另外，Goroutine 的栈是可以动态增长的，从 2KB 开始，最大可以到 1GB，这样既节省了内存，又避免了栈溢出的问题。

5. Goroutine什么时候会发生阻塞？¶

面试官：什么情况下 Goroutine 会发生阻塞？

回答：Goroutine 阻塞的场景还是挺多的，我总结一下主要的几种情况：

首先是 Channel 操作，这是最常见的。比如从一个没有数据的 channel 读取，或者往一个无缓冲的 channel 发送数据但没有接收者，这时候 Goroutine 就会阻塞等待。

然后是网络 I/O 操作，像 socket 读写、HTTP 请求这些，如果对方没有数据发送过来，Goroutine 就会阻塞等待。

还有系统调用，比如 time.Sleep、文件读写这些，会让 Goroutine 主动让出执行权。

互斥锁也是一个常见场景，当一个 Goroutine 尝试获取已经被其他 Goroutine 持有的锁时，就会阻塞等待锁释放。

最后是等待其他 Goroutine，比如使用 WaitGroup 的 Wait 方法，会阻塞直到所有相关的 Goroutine 都完成。

面试官：调度器是怎么处理这些阻塞的？

回答：当 Goroutine 阻塞时，Go 的调度器会把它从运行队列中移除，然后调度其他可运行的 Goroutine。这样就不会浪费 CPU 资源，整个程序的并发性能也不会受到影响。等阻塞条件解除后，Goroutine 会重新被放回运行队列等待调度。

6. PMG模型中Goroutine有哪几种状态？¶

面试官：在 GMP 模型中，Goroutine 有哪几种状态？

回答：Goroutine 的状态还是比较多的，我按照生命周期来说一下：

首先是 _Gidle，这是刚分配但还没初始化的状态。

然后是 _Grunnable，表示 Goroutine 已经在运行队列中，等待被调度执行。

_Grunning 就是正在执行的状态，这时候 Goroutine 占用着某个 P。

_Gsyscall 是执行系统调用的状态，这时候 M 会和 P 解绑，让其他 M 来接管 P。

_Gwaiting 是阻塞等待状态，比如等待 channel 操作、锁释放这些。

_Gdead 是执行完毕的状态，等待被回收复用。

还有两个特殊状态：_Gcopystack 是栈扩容时的状态，_Gpreempted 是被抢占时的状态。

面试官：这些状态是怎么流转的？

回答：典型的流转过程是：Gidle → Grunnable → Grunning，如果遇到阻塞就变成 Gwaiting，解除阻塞后又回到 Grunnable，最后执行完变成 Gdead。这个流转过程体现了 Go 调度器的精妙设计。

7. 每个线程/协程占用多少内存知道吗？¶

面试官：你知道系统线程和 Goroutine 分别占用多少内存吗？

回答：这个差别还是很大的。

系统线程在 Linux 上默认栈大小是 8MB，也就是说创建 1000 个线程就需要大约 8GB 内存，这个开销是相当大的。

而 Goroutine 就轻量多了，初始栈只有 2KB，而且是动态增长的，最大可以扩展到 1GB。按需扩容，通常以 2 倍的速度增长。

面试官：能量化一下这个差异吗？

回答：可以算一下，如果创建 100 万个 Goroutine，大概只需要 2GB 内存；但如果是系统线程，那就需要大约 8TB 内存，这根本不现实。

所以效率提升大概是 4000 倍左右，这也是为什么 Go 能够轻松支持百万级并发的原因。在我们的项目中，经常会有几十万个 Goroutine 同时运行，但内存占用还是很合理的。

8. 如果Goroutine一直占用资源怎么办，PMG模型怎么解决的这个问题？¶

面试官：如果有个 Goroutine 一直占用 CPU 不释放，GMP 模型是怎么处理的？

回答：这是个很好的问题，Go 的调度器确实考虑到了这种情况。

Go 的抢占机制经历了一个演进过程。在 Go 1.14 之前，主要是基于协作的抢占，就是在函数调用的时候检查抢占标志，如果需要让出就让出。但这种方式有个问题，如果是个纯计算的死循环，没有函数调用，就可能一直占用不释放。

从 Go 1.14 开始，引入了基于信号的抢占。调度器会发送 SIGURG 信号来强制抢占，即使是那种没有函数调用的死循环也能被抢占。

面试官：除了抢占，还有其他机制吗？

回答：还有 Work Stealing 算法。当一个 P 的本地队列空了，它会从其他 P 那里"偷"任务来执行，这样可以保证负载均衡。

另外还有个 Sysmon 监控线程，它会定期检查是否有长时间运行的 Goroutine，如果发现了会强制触发抢占调度。还会定期从全局队列调度 Goroutine，防止某些任务被饿死。

这些机制结合起来，基本上可以保证系统的公平性和响应性。

9. 如果若干线程中一个线程OOM，会发生什么？如果是Goroutine呢？项目中出现过OOM吗，怎么解决的？¶

面试官：如果系统线程发生 OOM，会怎么样？Goroutine 呢？

回答：这两种情况是不一样的。

如果是系统线程 OOM，通常整个进程都会崩溃，因为线程共享进程的内存空间，一个线程的内存问题会影响到整个进程。

但 Goroutine 的情况就不同了。如果是单个 Goroutine 的栈溢出，它会产生 panic，但这个 panic 是可以通过 recover 捕获的，而且不会影响其他 Goroutine 的正常运行。

面试官：你在项目中遇到过 OOM 问题吗？怎么解决的？

回答：遇到过几次，主要是在处理大量数据的时候。

首先我会用 pprof 来分析内存使用情况，在代码里导入 net/http/pprof 包，然后通过 /debug/pprof/heap 来查看内存分配情况。

然后针对性地优化，比如使用 sync.Pool 来复用对象，避免频繁的内存分配。对于大批量处理的场景，我会限制并发的 Goroutine 数量，用一个带缓冲的 channel 作为信号量来控制。

还有就是及时释放不需要的资源，比如关闭文件句柄、数据库连接这些。

最重要的是要有监控，我们会设置内存使用的告警阈值，这样能及时发现问题。

10. 项目中错误处理是怎么做的？¶

面试官：你在项目中是怎么做错误处理的？

回答：我们采用了多层次的错误处理策略。

首先是错误包装，我们使用 github.com/pkg/errors 这个库来包装错误，这样可以保留错误的调用栈信息。比如在文件操作失败时，我会用 errors.Wrap 来包装原始错误，添加更多的上下文信息。

然后是自定义错误类型，对于业务逻辑中的错误，我们定义了 BusinessError 结构体，包含错误码、错误信息和原始错误，这样可以更好地区分不同类型的错误。

在 Web 层面，我们有统一的错误处理中间件，使用 Gin 的 Recovery 中间件来捕获 panic，并且对不同类型的错误返回相应的 HTTP 状态码。

面试官：日志记录方面呢？

回答：日志方面我们使用 zap 做结构化日志，记录错误时会包含操作类型、用户ID、错误详情这些关键信息，方便后续的问题排查。

整体的原则就是：底层错误要包装，业务错误要分类，系统错误要记录，用户错误要友好。