golang面试题总结

go channel close后读写

非阻塞读，panic写
nil的channel，无论收发都会阻塞

io多路复用，select/poll/epoll的区别

select原则上是通过遍历fd句柄，查找到可读的句柄，所以时间复杂度为O(N)，epoll是将已经就绪的fd推送给应用层，所以时间复杂度为O(1)
select由于数据结构原因支持的句柄最大值为1024/2048个，poll为链表型结构，句柄无最大值。
epoll存储fd为红黑树结构，fd就绪后存储在就绪链表中，调用回调函数唤醒epoll_wait
https://blog.csdn.net/nanxiaotao/article/details/90612404

Linux进程调度原理

https://blog.csdn.net/zhoutaopower/article/details/86290196

进程间通信的方法

无名管道、有名管道、内核消息队列、共享内存、信号量、信号、socket

slice和array的区别

https://blog.csdn.net/u010918487/article/details/85490028

interface理解

是声明多个方法的集合，如果目标类型实现了接口中定义的所有方法，那么就视为实现了该接口

type iface struct {
	tab *itab
	data unsafe.Pointer
}

tab中包含三个字段，接口类型名称/接口方法集，实际对象类型，实际方法地址
只有当两个字段都为空时，才能和nil做判断

channel理解

type hchan struct {
	dataqsiz uint
	buf unsafe.Pointer
	elemsize uint16
	eletype *_type
}

https://mp.weixin.qq.com/s?__biz=MzUzMjk0ODI0OA==&mid=2247483766&idx=1&sn=eb605a64bed0b2066a12083f26fb04b6&chksm=faaa3501cdddbc177121ba14a6604743d5ea881ca8299d5609ac8eb9b6eca4f2a142ad5aabfd&token=1213124593&lang=zh_CN#rd

waitGroup理解

https://zhuanlan.zhihu.com/p/344973865

session存储

在分布式情况下session大都有两种存储策略，一种是通过hash将相同用户的请求打到同一台服务器上，这时只需要在当前机器上存储session就可以了；另外一种也可以设计一个session服务，专门存储用户session信息，或者直接使用缓存进行存储

map理解

https://studygolang.com/articles/14583
该文章的扩容触发条件有待还缺少了溢出桶的个数判断条件
在向 map 插入新 key 的时候，会进行条件检测，符合下面这 2 个 条件，就会触发扩容：

1 装载因子loadFactor := count / (2^B) 超过阈值，源码里定义的阈值是 6.5，此时会扩充一倍的bucket数量

2 overflow 的 bucket 数量过多：当 B 小于 15，overflow 的 bucket 数量超过 2^B；当 B >= 15，如果 overflow 的 bucket 数量超过 2^15，此时不会扩充Bucket，而是对原bucket做内存整理

map打印的无序是由于做了index随机播种，所以每次打印的起始节点可能不同，但是总体顺序是相同的，主要是为了解决多平台移植性的问题

日活和月活使用hyperloglog进行统计

https://zhuanlan.zhihu.com/p/69537466

golang中不可比较的类型

slice/map/function
个人理解slice和map是为了避免数据相同，但是存储地址不同的误会，而直接禁止了这两种类型的比较。

const可以修饰的类型

布尔型、数字型（整数型、浮点型和复数）和字符串型几种基本类型。

内存逃逸的几种情况

https://zhuanlan.zhihu.com/p/145468000

rockerMQ保证消息可靠性的方法

producer端：
可以采用同步阻塞式的发送（也就是发送同步消息），同步的检查Brocker返回的状态是否持久化成功，发送超时或者失败，则会默认重试2次，brocker选择了确保消息一定发送成功，但有可能发生重复投递
如果是异步发送消息，会有一个回调接口，当brocker存储成功或者失败的时候，也可以在这里根据返回状态来决定是否需要重试（当然这个是需要我们自己来实现的）
broker端：
rocketmq一般都是先把消息写到PageCache中，然后再持久化到磁盘上，数据从pagecache刷新到磁盘有两种方式，同步和异步
同步刷盘方式：消息写入内存的 PageCache后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态。这种方式可以保证数据绝对安全，但是吞吐量不大。
异步刷盘方式（默认）：消息写入到内存的 PageCache中，就立刻给客户端返回写操作成功，当 PageCache中的消息积累到一定的量时，触发一次写操作，将 PageCache中的消息写入到磁盘中。这种方式吞吐量大，性能高，但是 PageCache中的数据可能丢失，不能保证数据绝对的安全。
cousmer端：
cousmer端默认是消息之后自动返回消费成功确认ack,但是这时如果我们的程序执行失败了，数据不就丢失了吗？
所以我们可以将自动提交（AutoCommit）消费响应，设置为在代码中手动提交，只有真正消费成功之后再通知brocker消费成功，然后更新消费唯一offset或者删除brocker中的消息。
https://blog.csdn.net/qq_38545713/article/details/104758104

sync.Map源码解析

https://blog.csdn.net/u011957758/article/details/96633984?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-6.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-6.control

golang gmp对于syscall的调度

https://segmentfault.com/a/1190000039855617