go语言面试题框架(golang面试参考手册)

Go语言channel的阻塞问题

Hello，大家好，又见面了！上一遍乱肢我们将channel相关基础以及使用场景。这一篇，还需要再次进阶理解channel阻塞问题。以下创建一个chan类型为int，cap为3。

channel内部其实是一个环形buf数据结构，是一种滑动窗口机制，当make完后，就分配在Heap上。

上面，向chan发送一条“hello”数据：

如果G1发送数据超过指定cap时，会出现什么情况？

看下面实例：

以上会出现什么，chan缓冲区允许大小为1，如果再往chan仍数据，满了就会被阻塞，那么是如何实现阻塞的呢？当chan满时，会进入gopark，此时G1进入一个waiting状态，然后会创建一个sudog对象，其实就sendq队列，把200放进去。等buf不满的时候，再唤醒放入buf里面。

通过如下源码，你会更加清晰：

上面，从chan获取数据：

Go语言核心思想：“Donotcommunicatebysharingmemory;instead,sharememorybycommunicating.”你可以看看这本书名叫：EffectiveGo

如果接收者，接收一个空对象，也会发生什么情况？

代码示例：

也会报错如下：

上面，从chan取出数据，可是没有数据了。此时，它会把接收者G2阻塞掉，也是和G1发送者一样，也会执行gopark将状态改为waiting，不一样的点就是。

正常情况下，接收者G2作为取出数据是去buf读取数据的，但现在，buf为空了，此时，接收者G2会将sudog导出来，因为现在G2已经被阻塞了嘛，会把G2给G，然后将t:=-ch中变量t是在栈洞陪绝上的地址，放进去elem，也就是说，只存它的地址指针在sudog里面。

最后，ch-200当G1往chan添加200这个数据，正常情况是将数纳姿据添加到buf里面，然后唤醒G2是吧，而现在是将G1的添加200数据直接干到刚才G2阻塞的t这里变量里面。

你会认为，这样真的可以吗？想一想，G2本来就是已经阻塞了，然后我们直接这么干肯定没有什么毛病，而且效率提高了，不需要再次放入buf再取出，这个过程也是需要时间。不然，不得往chan添加数据需要加锁、拷贝、解锁一序列操作，那肯定就慢了，我想Go语言是为了高效及内存使用率的考虑这样设计的。（注意，一般都是在runtime里面完成，不然会出现象安全问题。）

总结：

chan类型的特点：chan如果为空，receiver接收数据的时候就会阻塞等待，直到chan被关闭或者有新的数据到来。有这种个机制，就可以实现wait/notify的设计模式。

相关面试题：

本文目录如下，阅读本文后，将一网打尽下面GolangMap相关面试题

Go中的map是一个指针，占用8个字节，指向hmap结构体;源码src/runtime/map.go中可以看到map的底层结构

每个map的底层结构是hmap，hmap包含若干个结构为bmap的bucket数组。每个bucket底层都采用链表结构。接下来，我们来详细看下map的结构

bmap就是我们常说的“桶”，一个桶里面会最多装8个key，这些key之所以会落入同一个桶，是因为它们经过哈希计算后，哈希结果是“一类”的，关于key的定位我们在map的查询和插入中详细说明。在桶内，又会根据key计算出来的hash值的高8位来决定key到底落入桶内的哪个位置（一个桶内最多有8个位置)。

bucket内存数据结构可视化如下：

注意到key和value是各自放在一起的，并不是key/value/key/value/...这样的形式。源码里说明这样的好处是在某些情况下可以省略掉padding字段，节省内存空间。

当map的key和value都不是指针，并且size都小于128字节的情况下，会把bmap标记为不含指针，这样可以避免gc时扫描整个hmap。但是，我们看bmap其实有一个overflow的字段，是指针类型的，破坏了bmap不含指针的设想，这时会把overflow移动到extra字段来。

map是个指针，底层指向hmap，所以是个氏码引用类型

golang有三个常用的高级类型slice、map、channel,它们都是引用类型，当引用类型作为函数参数时，可能会修改原内容数据。

golang中没有引用传递，只有值和指针传递。所以map作为函数实参传递时本质上也是值传递，只不过因为map底层数据结构是通过指针指向实际的元素存储空间，在被调函数中修改map，对调用者同样可见，所以map作为函数实参传递时表现出了引用传递的效果。

因此，传递map时，如果想修改map的内容而不是map本身，函数形参无需使用指针

map底层数据结构是通过指针指向实际的元素存储空间，这种情况下，对其中一个map的更改，会影响野族到其他map

map在没有被修改的情况下，使用range多次遍历map时输出的key和value的顺序可能不同。这是Go语言的设计者们有意为之，在每次range时的顺序被随机化，旨在提示开发者们，Go底层实现并不保证map遍历顺序稳定，请大家不要依赖range遍历结果顺序。

map本身是无序的，且遍历时顺序还会被随机化，如果想顺序遍历map，需要对mapkey先排序，再按照key的顺序遍历map。

map默认是并发不安全的，原因如下：

Go官方在经过了长时间的讨论后，认为Gomap更应适配典型使用场景（不需要从多个goroutine中进行安全访问），而不是为了小部分情况（并发访问），导致大部分程序付出加锁代价（性能），决定了不支持。

场景:2个协程同时读和写，以下程序会出现致命错误：fatalerror:concurrentmapwrites

如果想实现map线程安全，有两种方式：

方式一：使用读写锁map+sync.RWMutex

方式二：使用golang提供的sync.Map

sync.map是用读写分离实现的，其思想是空间换时间。和map+RWLock的实现方式相比，它做了一些优化：可以无锁访问readmap，而且会优先操作readmap，倘若只操作readmap就歼脊哪可以满足要求(增删改查遍历)，那就不用去操作writemap(它的读写都要加锁)，所以在某些特定场景中它发生锁竞争的频率会远远小于map+RWLock的实现方式。

golang中map是一个kv对集合。底层使用hashtable，用链表来解决冲突，出现冲突时，不是每一个key都申请一个结构通过链表串起来，而是以bmap为最小粒度挂载，一个bmap可以放8个kv。在哈希函数的选择上，会在程序启动时，检测cpu是否支持aes，如果支持，则使用aeshash，否则使用memhash。

map有3钟初始化方式，一般通过make方式创建

map的创建通过生成汇编码可以知道，make创建map时调用的底层函数是runtime.makemap。如果你的map初始容量小于等于8会发现走的是runtime.fastrand是因为容量小于8时不需要生成多个桶，一个桶的容量就可以满足

makemap函数会通过fastrand创建一个随机的哈希种子，然后根据传入的hint计算出需要的最小需要的桶的数量，最后再使用makeBucketArray创建用于保存桶的数组，这个方法其实就是根据传入的B计算出的需要创建的桶数量在内存中分配一片连续的空间用于存储数据，在创建桶的过程中还会额外创建一些用于保存溢出数据的桶，数量是2^(B-4)个。初始化完成返回hmap指针。

找到一个B，使得map的装载因子在正常范围内

Go语言中读取map有两种语法：带comma和不带comma。当要查询的key不在map里，带comma的用法会返回一个bool型变量提示key是否在map中；而不带comma的语句则会返回一个value类型的零值。如果value是int型就会返回0，如果value是string类型，就会返回空字符串。

map的查找通过生成汇编码可以知道，根据key的不同类型，编译器会将查找函数用更具体的函数替换，以优化效率：

函数首先会检查map的标志位flags。如果flags的写标志位此时被置1了，说明有其他协程在执行“写”操作，进而导致程序panic。这也说明了map对协程是不安全的。

key经过哈希函数计算后，得到的哈希值如下（主流64位机下共64个bit位）：

m:桶的个数

从buckets通过hashm得到对应的bucket，如果bucket正在扩容，并且没有扩容完成，则从oldbuckets得到对应的bucket

计算hash所在桶编号：

用上一步哈希值最后的5个bit位，也就是01010，值为10，也就是10号桶（范围是0~31号桶）

计算hash所在的槽位:

用上一步哈希值哈希值的高8个bit位，也就是10010111，转化为十进制，也就是151，在10号bucket中寻找**tophash值（HOBhash）为151*的槽位**，即为key所在位置，找到了2号槽位，这样整个查找过程就结束了。

如果在bucket中没找到，并且overflow不为空，还要继续去overflowbucket中寻找，直到找到或是所有的key槽位都找遍了，包括所有的overflowbucket。

通过上面找到了对应的槽位，这里我们再详细分析下key/value值是如何获取的：

bucket里key的起始地址就是unsafe.Pointer(b)+dataOffset。第i个key的地址就要在此基础上跨过i个key的大小；而我们又知道，value的地址是在所有key之后，因此第i个value的地址还需要加上所有key的偏移。

通过汇编语言可以看到，向map中插入或者修改key，最终调用的是mapassign函数。

实际上插入或修改key的语法是一样的，只不过前者操作的key在map中不存在，而后者操作的key存在map中。

mapassign有一个系列的函数，根据key类型的不同，编译器会将其优化为相应的“快速函数”。

我们只用研究最一般的赋值函数mapassign。

map的赋值会附带着map的扩容和迁移，map的扩容只是将底层数组扩大了一倍，并没有进行数据的转移，数据的转移是在扩容后逐步进行的，在迁移的过程中每进行一次赋值（access或者delete）会至少做一次迁移工作。

1.判断map是否为nil

每一次进行赋值/删除操作时，只要oldbuckets!=nil则认为正在扩容，会做一次迁移工作，下面会详细说下迁移过程

根据上面查找过程，查找key所在位置，如果找到则更新，没找到则找空位插入即可

经过前面迭代寻找动作，若没有找到可插入的位置，意味着需要扩容进行插入，下面会详细说下扩容过程

通过汇编语言可以看到，向map中删除key，最终调用的是mapdelete函数

删除的逻辑相对比较简单，大多函数在赋值操作中已经用到过，核心还是找到key的具体位置。寻找过程都是类似的，在bucket中挨个cell寻找。找到对应位置后，对key或者value进行“清零”操作，将count值减1，将对应位置的tophash值置成Empty

再来说触发map扩容的时机：在向map插入新key的时候，会进行条件检测，符合下面这2个条件，就会触发扩容：

1、装载因子超过阈值

源码里定义的阈值是6.5(loadFactorNum/loadFactorDen)，是经过测试后取出的一个比较合理的因子

我们知道，每个bucket有8个空位，在没有溢出，且所有的桶都装满了的情况下，装载因子算出来的结果是8。因此当装载因子超过6.5时，表明很多bucket都快要装满了，查找效率和插入效率都变低了。在这个时候进行扩容是有必要的。

对于条件1，元素太多，而bucket数量太少，很简单：将B加1，bucket最大数量(2^B)直接变成原来bucket数量的2倍。于是，就有新老bucket了。注意，这时候元素都在老bucket里，还没迁移到新的bucket来。新bucket只是最大数量变为原来最大数量的2倍(2^B*2)。

2、overflow的bucket数量过多

在装载因子比较小的情况下，这时候map的查找和插入效率也很低，而第1点识别不出来这种情况。表面现象就是计算装载因子的分子比较小，即map里元素总数少，但是bucket数量多（真实分配的bucket数量多，包括大量的overflowbucket）

不难想像造成这种情况的原因：不停地插入、删除元素。先插入很多元素，导致创建了很多bucket，但是装载因子达不到第1点的临界值，未触发扩容来缓解这种情况。之后，删除元素降低元素总数量，再插入很多元素，导致创建很多的overflowbucket，但就是不会触发第1点的规定，你能拿我怎么办？overflowbucket数量太多，导致key会很分散，查找插入效率低得吓人，因此出台第2点规定。这就像是一座空城，房子很多，但是住户很少，都分散了，找起人来很困难

对于条件2，其实元素没那么多，但是overflowbucket数特别多，说明很多bucket都没装满。解决办法就是开辟一个新bucket空间，将老bucket中的元素移动到新bucket，使得同一个bucket中的key排列地更紧密。这样，原来，在overflowbucket中的key可以移动到bucket中来。结果是节省空间，提高bucket利用率，map的查找和插入效率自然就会提升。

由于map扩容需要将原有的key/value重新搬迁到新的内存地址，如果有大量的key/value需要搬迁，会非常影响性能。因此Gomap的扩容采取了一种称为“渐进式”的方式，原有的key并不会一次性搬迁完毕，每次最多只会搬迁2个bucket。

上面说的hashGrow()函数实际上并没有真正地“搬迁”，它只是分配好了新的buckets，并将老的buckets挂到了oldbuckets字段上。真正搬迁buckets的动作在growWork()函数中，而调用growWork()函数的动作是在mapassign和mapdelete函数中。也就是插入或修改、删除key的时候，都会尝试进行搬迁buckets的工作。先检查oldbuckets是否搬迁完毕，具体来说就是检查oldbuckets是否为nil。

如果未迁移完毕，赋值/删除的时候，扩容完毕后（预分配内存），不会马上就进行迁移。而是采取增量扩容的方式，当有访问到具体bukcet时，才会逐渐的进行迁移（将oldbucket迁移到bucket）

nevacuate标识的是当前的进度，如果都搬迁完，应该和2^B的长度是一样的

在evacuate方法实现是把这个位置对应的bucket，以及其冲突链上的数据都转移到新的buckets上。

转移的判断直接通过tophash就可以，判断tophash中第一个hash值即可

遍历的过程，就是按顺序遍历bucket，同时按顺序遍历bucket中的key。

map遍历是无序的，如果想实现有序遍历，可以先对key进行排序

为什么遍历map是无序的？

如果发生过迁移，key的位置发生了重大的变化，有些key飞上高枝，有些key则原地不动。这样，遍历map的结果就不可能按原来的顺序了。

如果就一个写死的map，不会向map进行插入删除的操作，按理说每次遍历这样的map都会返回一个固定顺序的key/value序列吧。但是Go杜绝了这种做法，因为这样会给新手程序员带来误解，以为这是一定会发生的事情，在某些情况下，可能会酿成大错。

Go做得更绝，当我们在遍历map时，并不是固定地从0号bucket开始遍历，每次都是从一个**随机值序号的bucket开始遍历，并且是从这个bucket的一个随机序号的cell**开始遍历。这样，即使你是一个写死的map，仅仅只是遍历它，也不太可能会返回一个固定序列的key/value对了。

GO中的defer会在当前函数返回前执行传入的函数，常用于关闭文件描述符，关闭链接及解锁等操作。

Go语言中使用defer时会遇到两个常见问题：

接下来我们来详细处理这两个问题。

官方有段对defer的解释：

这里我们先来一道经典的面试题

你觉得这个会打印什么？

输出结果：

这里是遵循先入后出的原则，同时保留当前变量的值。

把这道题简化一下：

输出结果

上述代码输出似乎不符合预期，这个现象出现的原因是什么呢？经过分析，我们发现调用defer关键字会立即拷贝函数中引用的外部参数，所以fmt.Println(i)的这个i是在调用defer的时候就已经赋值了，所以会直接打印1。

想要解决这个问题也很简单，只需要向defer关键字传入匿名函数

这里把一些垃圾回收使用的字段忽略了。

中间代码生成阶段cmd/compile/internal/gc/ssa.go会处理程序中的defer，该函数会根据条件不同，使用三种机制来处理该关键字

开放编码、堆分配和栈分配是defer关键字的三种方法，而Go1.14加入的开放编码，使得关键字开销可以忽略不计。

call方法会为所有函数和方法调用生成中间代码，工作内容：

defer关键字在运行时会调用deferproc，这个函数实现在src/runtime/panic.go里，接受两个参数：参数的大小和闭包所在的地址。

编译器不仅将defer关键字转成deferproc函数，还会通过以下三种方式为所有调用defer的函数末尾插入deferreturn的函数调用

1、在cmd/compile/internal/gc/walk.go的walkstmt函数中，在遇到ODEFFER节点时会执行Curfn.Func.SetHasDefer(true)，设置当前函数的hasdefer属性

2、在ssa.go的buildssa会执行s.hasdefer=fn.Func.HasDefer()更新hasdefer

3、在exit中会根据hasdefer在函数返回前插入deferreturn的函喊羡搭数调用

runtime.deferproc为defer创建了一个runtime._defer结构体、设置它的函数指针fn、程序计数器pc和栈指针sp并将相关参数拷贝到相邻的内存空间中

最后调用的return0是唯一一个不会触发延迟调用的函数，可以避免deferreturn的递归调用。

newdefer的分配方式是从pool缓存池中获取：

这三种方式取到的结构体_defer，都会被添加到链表的队头，这也是为什么defer按照后进先出的顺序执行。

deferreturn就是从链表的队头取出并调用jmpdefer传入需要执行的函数和参数。

该函数只有在所有延迟函数都执行后才会返回。

如果我们能够将部分结构体分配到栈上就可以节约内存分配带来的额外开销。

在call函数中有在栈上分配

在运行期间deferprocStack只需要设置一些未在编译期间初始化的字段，就可以将栈上的_defer追加到函数的链表上。

除了分配的位置和堆的不同，其他的大致相同。

Go语言在1.14中通过开放编码实现defer关键字，使用代码内联优化defer关键的额外开销并引入函数数据派空funcdata管理panic的调用，该优化可以将defer的调用开销从1.13版本的~35ns降低至~6ns左右。

然而开放编码作为一种优化defer关键字的方法，它不是在所有的场景下都会开启的，开放编码只会在满足以下的条件时启用：

如果函数中defer关键字的数量多于8个或者defer处于循环中，那么就会禁用郑拿开放编码优化。

可以看到这里，判断编译参数不用-N，返回语句的数量和defer数量的乘积小于15，会启用开放编码优化。

延迟比特deferBitsTemp和延迟记录是使用开放编码实现defer的两个最重要的结构，一旦使用开放编码，buildssa会在栈上初始化大小为8个比特的deferBits

延迟比特中的每一个比特位都表示该位对应的defer关键字是否需要被执行。延迟比特的作用就是标记哪些defer关键字在函数中被执行，这样就能在函数返回时根据对应的deferBits确定要执行的函数。

而deferBits的大小为8比特，所以该优化的条件就是defer的数量小于8.

而执行延迟调用的时候仍在deferreturn

这里做了特殊的优化，在runOpenDeferFrame执行开放编码延迟函数

1、从结构体_defer读取deferBits，执行函数等信息

2、在循环中依次读取执行函数的地址和参数信息，并通过deferBits判断是否要执行

3、调用reflectcallSave执行函数

1、新加入的defer放入队头，执行defer时是从队头取函数调用，所以是后进先出

2、通过判断defer关键字、return数量来判断是否开启开放编码优化

3、调用deferproc函数创建新的延迟调用函数时，会立即拷贝函数