context

context实际上是一个接口，提供了四种方法 Done(),Deadline(),Err(),Value()，可以在一个请求链路中，优雅地传递取消信号，超时，和截止日期，并且携带一些范围内的键值对数据

context主要解决三个问题：超时取消，请求信号传播，请求级数据传递

• 当超时发生时，所有子操作都会收到通知，立刻退出
• 可以传递请求级的原数据，比如用户id等

查找

context的查找是链式的，当前层级没有需要的key，就调用parent.Value()继续往上查找，这个过程会一直递归直到找到对应的key或者返回nil

取消

context的取消主要是通过channel关闭实现的，有三种方法

• 超时取消：调用定时器，超时自动cancel
• 主动取消：创建的时候返回一个cancel函数，调用就会关闭done channel，所有的调用这个context的groutine都可以通过done方法获得通知
• 级联取消：父context被取消的时候，下面的所有子context也会被取消

interface

interface包括动态类型和动态值 eface是不带方法的interface得实现，包含数据指针和类型指针

type eface struct {
    _type *_type
    data  unsafe.Pointer
}

iface是带接口的interface实现

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

包含itab和data，itab存储了接口类型，具体类型，方法表，方法表是个函数指针数组，保存了该实现方法所有接口方法的地址

类型转换和类型断言的区别

类型转换：T(Value)是在编译期确定的强制转换，转换前后的✌️类型要互相兼容 类型断言：Value.(T)是运行期的动态检查，从接口中提取具体类型

• 类型转换在编译期保证成功，而类型断言在编译期有可能失败
• 类型转换底层是简单的数据结构转换，而类型断言涉及到底层接口类型
• 使用场景不同，类型转换用户字符串，数字之间互相转换，类型断言用于接口编程

应用

• 依赖注入：通过定义接口抽象，让高层代码不依赖具体实现
• 类型断言和反射配合使用：orm

mutex

结构

type mutex struct {
    state int32
    sema   uint32
}

state表示锁的状态，有锁定，被唤醒，饥饿状态

sema表示信号量，mutex阻塞队列的定位，实现groutine的阻塞和唤醒

模式

Mutex基本上有两种模式：饥饿模式和正常模式：

• 正常模式：新请求的锁会和头部等待的groutine竞争，在等待期间会自旋几次，如果此时锁资源恰好被释放，那么新的请求有概率抢到锁，这样头部等待的groutine可能需要等很久才能抢到锁。这种方式吞吐量极高。
• 饥饿模式：当一个groutine在队列中等待超过1ms，就会切换到这种模式。在这种模式下，解锁后锁的所有权会给头部groutine，新的请求groutine排在队尾等待

当等待队列为空，或者获取锁的时间小于1ms，就会切换回正常模式

sync.once

保证函数不管在多少个groutine中被调用，都只执行一次

type once struct {
    done uint32
    m  mutex
}

WaitGroup

waitgroup用来等待一组groutine全部执行完成

调用 Add() 来增加计数值groutine数量

调用 Done() 来减少计数值groutine数量

Wait() 方法会检查这个计数值，当他不等于0的时候，groutine会被挂起，直到Done() 后计数值为0，通知当前等待的所有groutine停止阻塞等待

type WaitGroup struct {
    noCopy noCopy
    state atomic.Uint64
    sema  uint32
} 

nocopy：用于检查waitgroup是否被复制，被复制后会导致状态不一致，可能引发程序错误 state：高32位是计数器，激励等待的groutine数量，低32位是调用Wait() 方法之后被阻塞的groutine数量

sync.map

针对多个线程同时读写map的场景，有sync.map,避免普通map并发读写导致的异常或者panic

它通过内部的 read-only 和 dirty 等结构减少锁竞争，但不意味着所有场景下都比普通 map 加 mutex 更快。sync.map针对多读少写的操作

sync.map的思路是用空间换时间，通过read和dirty两个结构实现快速读写

type Map struct {
    mu     Mutex
    read   atomic.Pointer[readOnly]
    dirty  map[any]*entry
    misses int
}

miss记录在read中读取值的时候没有命中的次数，到一定程度之后触发同步

read是一个只读的map，提供无锁的并发读取，速度极快

写操作先通过锁操作一个dirtymap，当dirtymap的数据过多或者读到一个不存在的key的时候，会将数据迁移并覆盖旧read，完成一次数据同步

read是只读的，当用户删除一个键的时候，通过把这个建在read中entry改为nil，只要是nil就代表该建不存在，而在需要基于read重建dirty的时候，会检查所有entry为nil的建，标记为enpunged，表示该建不再复制到新的dirty中。如果后续要写一个标记为enpunged的建，必须先回退到nil，再进行写入 收起

MAP

map底层结构

type hmap struct {
    count     int   //map中元素的个数
    flags     uint8 //标志位，记录map状态
    B         uint8 //bucket数量
    noverflow uint16    //溢出桶数量近似值
    hash0     uint32    //hash种子

    buckets    unsafe.Pointer   //指向bucket的指针
    oldbuckets unsafe.Pointer   //旧bucket
    nevacuate  uintptr  //表示扩容进度，小于该值的桶已完成迁移

    extra *mapextra //指向mapextra的指针，存放溢出桶
}


type mapextra struct {
    overflow    *[]*bmap
    oldoverflow *[]*bmap
    nextOverflow *bmap
}

在map中查找对应的keyValue

Go的map通过hash(key)计算出一个hash值，hash值的低位对应bucket下标，在对应bucket的8个槽中先比较hash值的高位和tophash，tophash可以排除大量不匹配的key，减少时间。找到tophash之后检查key是否相同，避免hash冲突找错key，如果符合返回对应值，如果不符合，检查overflow，直到找到key或者整个链条检查完。

map扩容机制

向map中插入新key的时候，符合以下两个条件就会触发扩容

1. 装载因子超过阈值6.5触发双倍扩容，B+1，bucket数量翻倍 装载因子是哈希表中已经存储的元素数量 ÷ 哈希桶的数量，用来衡量哈希表有多“满”。

2. overflow bucket数量过多，触发等量扩容，B不会变，让排列更紧凑 overflow bucket（溢出桶）就是当一个 bucket 已经放满 8 个键值对，但又有新的 key 哈希到了这个 bucket 时，额外拿来存放这些数据的 bucket。

bucket 0
┌──────────────────────┐
│ key1 │ key2 │ ... │key8│
└──────────┬───────────┘
           │
           ↓
      overflow bucket
      ┌──────────────────┐
      │ key9 │ key10 │...│
      └──────────────────┘

map的扩容是渐进式，再触发扩容时不会一次性迁移数据，而是下一次操作的时候顺便迁移一两个桶的数据，将庞大的扩容成本迁移到多次操作之中，减少了服务的瞬间延迟 5

map的安全性

map并非线程安全，map的底层不是不可分割的原子操作 Go的普通 map 没有提供并发访问时的同步机制，因此多个 goroutine 同时读写可能产生数据竞争，甚至直接触发运行时的 concurrent map read and map write。

可以通过加sync.RWMutex来保证读写安全

因为同步会带来额外开销，而很多场景下 map 根本不需要并发保护；把同步责任交给使用者，可以让普通 map 在单线程/自行同步的场景下保持更高性能和更简单的语义。

Channel

CSP

csp为并发编程模型，通过通信共享内存而不是通过共享内存来通信

底层模型

channel的底层是一个 hchan 结构体

type hchan struct {
    qcount   uint           // 当前队列中元素数量
    dataqsiz uint           // 环形队列容量
    buf      unsafe.Pointer // 环形队列缓冲区

    elemsize uint16         // 每个元素大小
    closed   uint32         // channel 是否关闭

    elemtype *_type         // 元素类型

    sendx    uint           // 下一次发送的位置
    recvx    uint           // 下一次接收的位置

    recvq    waitq          // 等待接收的 goroutine
    sendq    waitq          // 等待发送的 goroutine

    lock     mutex          // 保护 channel
}

环形缓冲区：buf指针指向环形缓冲区，sendx和recvx记录下一次发送和接受的位置

互斥锁：所有读写操作都需要先获取锁，go内部通过调度减少性能开销

等待队列：sendq和recvq分别用来存储发送阻塞的channel和接受阻塞的channel，这些队列用双向链表实现，条件满足时唤起对应的gourtine

sudog是什么：记录哪个 goroutine 因为什么原因正在这个 channel 上等待？的结构体

channel怎么唤醒阻塞的gourtine：

阻塞的 goroutine 会通过 sudog 加入 channel 的 sendq 或 recvq。当另一方进行发送或接收时，runtime 会从对应等待队列中取出 sudog，通过 goready 将对应 goroutine 从等待状态转为 runnable，之后由 Go 调度器重新调度执行。

发送数据过程

向某个channel发送数据之后

• 首先检查channel的recvq是否为空，如果不为空，证明有等待接受的groutine，那么优先向这个groutine传递数据，跳过缓冲区

• 没有接受者则写入缓冲区，检查缓冲区是否还有位置，当前队列中元素数量小于队列容量的时候，继续写入sendx下标位置，调用gopark让当前goutine阻塞，让出cpu

• 如果缓冲区满了，创建一个sudog，加入sendq阻塞等待调用gopark让当前goutine阻塞，让出cpu

  读取数据的过程与发送数据流程大致相同

• 向已经关闭的channel写入数据会触发panic，向已经关闭的channel读数据，如果缓冲区有数据仍然能读到，只有返回的ok为false的时候，读出的数据无效

select的执行机制

select会检查哪个case满足条件可以执行，如果有多个case满足条件，select会随机选择一个执行，如果没有case可以执行，要么default，没有default的时候阻塞等待

注册select的时候

创建select -> 注册case -> 执行select -> 释放select

case随机化➕双重循环检测：

定义select的时候会定义scase，存放所有case数据包括default，在runtime层面实现

case会随机排序，第一次轮询检测的时候检查是否有case符合要求，如果没有进行第二次检测，第二次检测把当前groutine加入等待接收队列或者等待发送队列，调用gopark让出cpu 收起