在goroutine的应用中，有些经典场景如：超时控制、派生goroutine管理、通用上下文传递等，因此官方在1.7版本引入了context库来提供便捷的解决方案。

根据官网对defer的描述，

defer func()的存储结构是栈，即LIFO，有多次defer调用时遵循后进先出的逻辑进行执行

而go中return的逻辑如下

1. 先将返回值赋值
2. 执行 defer 栈
3. 返回调用函数

• 举个栗子

1
2
3
4
5
6
7
8
9

func demo() (res int) {
for i := 1; i < 4; i++ {
defer func() {
res = i * i
fmt.Printf("res:\t%d\n", res)
}()
}
return
}

函数返回值为 1，终端输出如下：

1
2
3

res:9
res:4
res:1

今天在使用 github.com/spf13/viper 加载配置文件时突然发现有几个字段的值始终无法正常加载，大致形如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

type Config struct {
Name   string `yaml:"name"`
UserId int    `yaml:"user_id"`
}

func GetSnakeValue() Config {
v := viper.New()
v.Set("user_id", 1)
v.Set("name", "victor")
var cfg Config
err := v.Unmarshal(&cfg)
if err != nil {
panic(err)
}
return cfg
}

执行结果如下：

1
2
3
4

Config{
Name:   "victor",
UserId: 0
}

明显不符合预期：

1
2
3
4

Config{
Name:   "victor",
UserId: 1
}

现象分析

1. Config.Name 可以正常加载，那说明 viper 正常工作了
2. 在断点中可以看到 user_id 正常加载，继续断点下去是一些反射代码，没法直观分析
3. Config.UserId 无法正常加载，那么说明在decode时失败

根据网上资料得知，viper.Unmarshal 底层其实是用 mapstructure.Decode，但它对 tag、key 的处理有自己的默认行为：

• 会把所有 key 转换成 小写。
• 默认不会启用 WeaklyTypedInput、Squash 等高级选项。
• 不会自动启用驼峰 → 下划线的映射。

解决方案

知道了原因，那么就可以按图索骥。

1. 将tag的value改为驼峰写法，userId这样就可以正常解析

2. 添加mapstructure tag 让mapstructure.Decode知道 user_id对应的 struct field，如：

   1 2 3 4

   type Config struct { Name string `yaml:"name"` UserId int `yaml:"user_id" mapstructure:"user_id"` }

3. 在调用func (v *Viper) Unmarshal(rawVal any, opts ...DecoderConfigOption) error时，设置DecoderConfigOption

1
2
3
4

type Server struct {
Port     int
Protocol string
}

• 构造器

1
2
3
4
5
6

func NewServer(port int, protocol string) *Server{
return &Server{
Port: port,
Protocol: protocol,
}
}

简单直接，参数少的时候很常用。

• functional-option

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type Option func(server *Server)

func WithPort(port int) Option {
return func(server *Server) {
server.Port = port
}
}

func WithProtocol(protocol string) Option {
return func(server *Server) {
server.Protocol = protocol
}
}

func NewServerWithOption(options ...Option) *Server {
server := &Server{}
for _, option := range options {
option(server)
}
return server
}

直观，拓展性好，新增属性时只需要添加代码即可，不需要修改原有构造对象的代码。

• builder

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

type ServerBuilder struct {
option Server
}

func NewServerBuilder() *ServerBuilder {
return &ServerBuilder{}
}

func (b *ServerBuilder) WithPort(port int) *ServerBuilder {
b.option.Port = port
return b
}

func (b *ServerBuilder) WithProtocol(protocol string) *ServerBuilder {
b.option.Protocol = protocol
return b
}

func (b *ServerBuilder) Build() *Server {
return &b.option
}

适合复杂对象的构造，因为支持链式调用，所以需要分布进行构造对象时为首选。

1
2
3
4
5
6
7
8
9
10
11

type keyType struct{}

var ctxKey = keyType{}

func FromContext(ctx context.Context) (OrgUser, error) {
if orgUser, ok := ctx.Value(ctxKey).(OrgUser); !ok {
return orgUser, errors.New("OrgUser not found")
} else {
return orgUser, nil
}
}

细一思索发现这种实现很巧妙，虽然 ctxKey 实际上只是一个空 struct ，但是 golang 中对于值的比对分为两部分，一部分是 type ，一部分是 value ，两者完全相同，才会视为相等。
上述代码中，keyType 为私有类型，外部正常途径无法获得这种类型，也就避免了会有 ctx 的 key 与 ctxKey 相同，此外空 struct 也不占用额外内存。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type Context interface {

Deadline() (deadline time.Time, ok bool)

Done() <-chan struct{}

Err() error

Value(key any) any
}

type valueCtx struct {
Context
key, val any
}

仔细看才发现可以通过把 interface 内嵌到 struct 中来达到不实现 interface 的全部 method 就能使用实例指代 interface。
示例如下:

1
2
3
4
5
6
7
8
9
10
11
12
13

type Info interface {
Name() string
Age() int
}

type Cow struct {
name string
Info
}

func (c *Cow) Name() string {
return c.name
}

测试代码如下：

1
2
3
4
5
6
7
8
9
10

func TestName(t *testing.T) {
cow := &Cow{
name: "cc",
}
cl := func(i Info) string {
return i.Name()
}

t.Log(cl(cow))
}

输出：

1
2
3
4

=== RUN   TestName
    interface_in_struct_test.go:15: cc
--- PASS: TestName (0.00s)
PASS

可以清楚看到，Cow 对象没有实现 Info.Age 但是依旧可以使用实例 cow 作为入参，并能正常输出。

最近发现自动化任务里的网易云音乐私有文件(ncm)不能直接备份为公共文件格式(flac、aac、mp3等)。

• 现象分析

把之前yoki123的ncmdump项目打开debug发现

应该是做convention时出现了字段不匹配的问题。

解析ncm的meta信息可得

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "musicId" : "2308549",
  "musicName" : "My Heart Will Go On",
  "artist" : [ [ "Céline Dion", "50893" ] ],
  "albumId" : "232952",
  "album" : "Complete Best",
  "albumPicDocId" : "941181953423930",
  "albumPic" : "http://p4.music.126.net/fiNTK9Jvhg0V8QBJx0cXPg==/941181953423930.jpg",
  "bitrate" : 999000,
  "mp3DocId" : "0524b583bd4091bdf34be9406fb0b102",
  "duration" : 280333,
  "mvId" : "22617298",
  "alias" : [ ],
  "transNames" : [ "我心永恒" ],
  "format" : "flac",
  "fee" : 8,
  "volumeDelta" : -4.4074,
  "privilege" : {
    "flag" : 2064644
  }
}

而meta结构定义为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

type Album struct {
Id       float64 `json:"albumId"`
Name     string  `json:"album"`
CoverUrl string  `json:"albumPic"`
}

type Artist struct {
Name string
Id   float64
}

// @ref https://music.163.com/#/song?id={id}
type Meta struct {
Id       float64 `json:"musicId"`
Name     string  `json:"musicName"`
*Album   `json:",inline"`
Artists  []Artist `json:"artist"`
BitRate  float64  `json:"bitrate"`
Duration float64  `json:"duration"`
Format   string   `json:"format"`
Comment  string   `json:"-"`
}

发现 musicId、albumId和artistId从float类型调整为了string。

• 解决方案

将对应字段调整类型，对解析方法稍作调整，即可正常运行。

在源码中channel的数据结构大体如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

type hchan struct {
// chan 里元素数量
qcount   uint
// chan 底层循环数组的长度
dataqsiz uint
// 指向底层循环数组的指针
// 只针对有缓冲的 channel
buf      unsafe.Pointer
// chan 中元素大小
elemsize uint16
// chan 是否被关闭的标志
closed   uint32
// chan 中元素类型
elemtype *_type // element type
// 已发送元素在循环数组中的索引
sendx    uint   // send index
// 已接收元素在循环数组中的索引
recvx    uint   // receive index
// 等待接收的 goroutine 队列
recvq    waitq  // list of recv waiters
// 等待发送的 goroutine 队列
sendq    waitq  // list of send waiters

// 保护 hchan 中所有字段 保证原子性
lock mutex
}

创建一个容量为 6 的，元素为 int 型的 channel 数据结构如下 ：

• 写入数据

• 接收数据

• 注意事项

必须值得注意的是：

关闭 channel 后，对于等待接收者而言，会收到一个相应类型的零值

优雅关闭channel, 根据 sender 和 receiver 的个数，分下面几种情况：

1. 一个 sender， M 个 receiver， 直接在sender端关闭，用双值语句检查是否关闭
2. N 个 sender，一个 reciver，提供一个关闭信号channel，reciver端发送信号(关闭信号channel)
3. N 个 sender， M 个 receiver，协调好全体发送者，只关闭一次即可。

• 常见应用

• 协程池

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

func main() {
taskCh := make(chan int, 100)
go worker(taskCh)

    // 塞任务
for i := 0; i < 10; i++ {
taskCh <- i
}

    // 等待 1 小时 
select {
case <-time.After(time.Hour):
}
}

func worker(taskCh <-chan int) {
const N = 5
// 启动 5 个工作协程
for i := 0; i < N; i++ {
go func(id int) {
for {
task := <- taskCh
fmt.Printf("finish task: %d by worker %d\n", task, id)
time.Sleep(time.Second)
}
}(i)
}
}

• 限流

1
2
3
4
5
6
7
8
9
10
11
12
13

var limit = make(chan int, 3)

func main() {
    // …………
    for _, w := range work {
        go func() {
            limit <- 1
            w()
            <-limit
        }()
    }
    // …………
}

• ref

go-questions: channel

Runtime 会在程序启动的时候，创建 M 个线程（CPU 执行调度的单位），之后创建的 N 个 goroutine 都会依附在这 M 个线程上执行。

• scheduler调度

1. P先从自己的本地runnable queue找一个G
2. 要是没找到，就去别的P上找
3. 没找到就去Global runnable queue找
4. 还没找到就要去network poller中找阻塞在网络请求中的G
   此外， 每61次会强行去 Global runnable queue 找 G

• GMP运行的简单流程

1. Goroutine 创建：当使用 go 关键字创建一个新的 Goroutine 时，它会被放入 P 的本地队列若本地队列已满会放到调度器的全局队列中。
2. 调度器调度：Go 的调度器会将 Goroutine 分配给一个 P，P 会尝试在其本地队列中执行 Goroutine。如果本地队列已满或长时间未执行，Goroutine 会被放入全局队列。
3. M 的执行：M 会从 P 的本地队列或全局队列中取出 Goroutine 并执行。当 M 空闲时，它会尝试从全局队列或其他 P 的本地队列中 “窃取” Goroutine 来执行，这种机制称为 “work stealing”。

• 如何保证执行死循环的 Goroutine 不会一直抢占M

1. 系统信号: 调度器会周期性地向运行 Goroutine 的 M 线程发送一个系统信号（SIGURG）。

   栈扫描: 当 M 线程接收到这个信号后，会异步地暂停正在执行的 Goroutine。

   栈检查: 调度器会检查这个 Goroutine 的栈，寻找一个“安全点”。所谓安全点，就是指 Goroutine 的执行状态是可中断的。

   抢占: 如果找到了安全点，调度器会修改 Goroutine 的栈，将其标记为可抢占，并将其放入全局队列或本地队列。

   切换: M 线程随后就会去执行其他 Goroutine。

2. 在发生系统调用、阻塞操作时，goroutine会被挂起，切换到其他goroutine

红黑树是一种自平衡二叉搜索树 (任意节点的左子树的值均小于该节点，任意节点右子树的值均大于该节点，在插入删除节点后自动调整树的结构保证树的高度平衡，即任意节点的左右子树高度差不大于1) , 红黑树的节点会有颜色区分，不是红色就是黑色。

1. 叶子结点*(没有子结点的节点)*、根结点、空节点为黑色
2. 红色结点的子结点为黑色
3. 任意节点到叶子结点所有路径上的黑色结点数目一致

• 操作

• 旋转

为保证二叉树平衡，在插入删除节点后可能会通过旋转操作保持平衡。

• 插入

红黑树插入一个新结点的过程RB_INSERT是在二叉查找树插入过程的基础上改进的，先按照二叉排序的插入过程插入到红黑树中，然后将新插入的结点标记为红色，然后调用一个辅助的过程RB_INSERT_FIXUP来调整结点并重新着色，使得满足红黑树的性质。

• 删除

红黑树删除结点过程是在二叉查找树删除结点过程的基础改进的。与二叉查找树类似，删除的结点分为三种情况：

1. 无左右孩子
2. 有左孩子或者右孩子
3. 既左孩子又有右孩子

红黑树在删除结点后需要检查是否破坏了红黑树的性质。如果删除的结点y是红色的，则删除后的树仍然是保持红黑树的性质，因为树中各个结点的黑高度没有改变，不存在两个相邻（父结点和子结点）的红色结点，y是红色不可能是根，所有根仍然是黑色。如果删除的结点z是黑色的，则这个是破坏了红黑树的性质，需要调用RB_DELETE_FIXUP进行调整。从删除结点y的唯一孩子结点x或者是NIL处开始调整。

• ref

红黑树详解

1. 解析：检查语法和语义，生成解析树。

2. 预处理：参数化处理（如果有参数）。

3. 优化：查询优化器选择最优的执行计划。

4. 执行：按照执行计划，读写数据，对数据进行整理。

5. 结果返回：将结果集返回给客户端。

6. 清理：释放资源，记录日志。

• mysql的锁

• 共享锁&排他锁

• 共享锁
  读锁，允许多个事务同时读取同一数据，但不允许其他事务修改。
  查询操作，读多写少

• 排他锁
  写锁，仅允许一个事务在执行阶段访问数据，不允许其他事务读取、修改。
  更新删除操作，写多读少

• 乐观锁&悲观锁

• 乐观锁
  假设事务执行过程中数据不会被修改，仅在提交事务时会检查数据是否被修改*(时间戳、版本号)*
  加锁时间短，并发性能好，适合读多写少

• 悲观锁
  假设事务执行过程中数据可能被修改，在读取数据时就加锁，事务结束释放锁。
  加锁时间长，并发性能差，适合写频繁场景，有效避免数据冲突

• 如何解决死锁

• 预防

1. 按顺序加锁
2. 使用事务隔离级别
3. 减少事务持有锁的时间，将大事务拆成多个小事务
4. 读多写少的场景，使用乐观锁
5. 避免事务嵌套

• 处理

1. 设置事务的超时时间*(innodb_lock_wait_timeout)*，超时自动会滚
2. 回滚重试，程序检测到死锁异常时，手动回滚重试
3. 数据库会存在死锁检测，检测到以后会自动选择一个事务回滚

• 存储引擎

• InnoDB

mysql的默认事务存储引擎，支持事务ACID(原子性、一致性、隔离性、持久性)、行级锁、外间约束、多版本并发控制(MVCC)与聚簇索引等特点。

• 索引

用于加速数据库数据检索的一种数据结构，索引检索数据不需要扫描整个表，即可直接定位到对应数据。

1. 能提高查询速度
2. 需要占用额外空间
3. 影响写操作性能(需要维护索引)

• 索引类型

按数据结构：

按数据存储角度：

业务使用角度：

hash索引&自适应hash索引：

• 辅助索引的查询过程

1. 先根据条件查询到对应索引，若索引覆盖(查询的列全在辅助索引的数据列中)，直接从索引返回数据
2. 若不满足索引覆盖，根据索引中的数据行地址，查询实际的数据行，返回数据

• 联合索引的查询过程

联合索引(复合索引，包含多个列的索引)，

1. 解析查询条件，与所需筛选的列
2. 选择索引
3. 依据最左匹配原则(按索引顺序与查询条件进行匹配)，逐级分次匹配到满足条件的数据行
4. 若满足索引覆盖则直接返回数据，若不满足则需要回表查询

• 主键索引与非主键索引查询的区别是什么

主键索引叶子结点存储了整个数据行的数据，所以不会存在回表查询，而非主键索引可能会出现索引不覆盖的情况需要回表查询

• InnoDB索引采用B+Tree而不是其他数据结构的原因

红黑树等二叉搜索树的出度*(分叉个数、子结点数码)*最多为2，会导致树高相对更高，在查询时会io次数更多，效率更低。
b+Tree的数据全在叶子结点中，叶子结点是一个有序连表，而bTree结点数据分布在所有节点中。

高效的范围查询：叶子节点的有序链表使得范围查询非常高效。
减少磁盘 I/O：内部节点只存储键值和指针，同样空间下可以存储更多结点，减少树的高度，减少磁盘访问次数。
更好的缓存性能：更多的节点可以被缓存，提高查询性能。
高度平衡：所有叶子节点在同一层，保证了稳定的查询性能。
高效的插入和删除操作：主要影响叶子节点，减少内部节点的调整。

• 执行与优化

• EXPLAIN

explain关键字用于分析sql语句的执行情况，可以通过他进行sql语句的性能分析。

type：表示连接类型，从好到差的类型排序为

• system：系统表，数据已经加载到内存里。
• const：常量连接，通过索引一次就找到。
• eq_ref：唯一性索引扫描，返回所有匹配某个单独值的行。
• ref：非主键非唯一索引等值扫描，const或eq_ref改为普通非唯一索引。
• range：范围扫描，在索引上扫码特定范围内的值。
• index：索引树扫描，扫描索引上的全部数据。
• all：全表扫描。

key：显示MySQL实际决定使用的键。

key_len：显示MySQL决定使用的键长度，长度越短越好

Extra：额外信息

• Using filesort：MySQL使用外部的索引排序，很慢需要优化。

• Using temporary：使用了临时表保存中间结果，很慢需要优化。

• Using index：使用了覆盖索引。

• Using where：使用了where。

• 简述优化过程

1. 通过慢日志定位执行较慢的SQL语句
2. 利用explain对这些关键字段进行分析
3. 根据分析结果进行优化

• 分库分表

垂直分库：将不同业务模块数据分离到不同数据库
水平分库：按照一定规则将数据分散到多个数据库
垂直分表：将表中不同字段按业务逻辑分离
水平分表：按特定规则将表数据分到多个表

• log

• redo log与binlog的区别

1. redo log是InnoDB引擎特有的，只记录该引擎中表的修改记录。binlog是MySQL的Server层实现
   的，会记录所有引擎对数据库的修改。
2. redo log是物理日志，记录的是在具体某个数据页上做了什么修改；binlog是逻辑日志，记录的是这
   个语句的原始逻辑。
3. redo log是循环写的，空间固定会用完；binlog是可以追加写入的，binlog文件写到一定大小后会切
   换到下一个，并不会覆盖以前的日志。

• crash-safe能力是什么

InnoDB通过redo log保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crashsafe。

• 事务

• 简述

  是数据库中用于确保数据一致性和完整性的机制。具体来讲，事务是一连串数据库操作的集合，这些操作要么全部执行，要么全部不执行，以保证数据库的一致状态。
  主要特性如下(ACID):

  特性	memo
  原子性	事务是一个不可分割的最小工作单位，事务中的所有操作要么全部成功，要么全部失败。如果事务中的任何一个操作失败，整个事务都会回滚，撤销所有已经完成的操作
  一致性	事务必须保证数据库从一个一致状态转换到另一个一致状态。事务执行前后，数据库的完整性约束必须保持不变
  隔离性	多个事务并发执行时，每个事务的执行不应受到其他事务的影响。事务的隔离性确保了事务之间的独立性，避免了修改丢失、脏读、不可重复读和幻读等问题
  持久性	一旦事务提交，其对数据库的更改将是永久的，即使系统发生故障也不会丢失

脏读：读取了另一个事务尚未提交的数据。
不可重复读：在一个事务中，多次读取同一数据行得到的结果不一致。
幻读：在一个事务中，多次执行相同的查询，但结果集不同。

• 多个事务同时进行可能会出现什么问题

修改丢失、脏读、不可重复读和幻读等。

• 隔离界别

• MVCC

多版本并发控制（MVCC）通过生成和管理数据行的多个版本，减少了锁的竞争，提高了数据库的并发性能。MVCC 允许多个事务同时读取和写入数据，而不会相互干扰，从而支持更高效的并发操作。

• 读提交和可重复读都基于MVCC实现，有什么区别

• 读已提交：每次读取操作都会看到最新的已提交数据，可能产生不可重复读。

• 可重复读：事务在开始时会看到一个快照，避免不可重复读，但可能产生幻读。

• InnoDB如何保证事务的原子性、持久性和一致性

1. 利用undo log保障原子性。该log保存了事务发生之前的数据的一个版本，可以用于回滚，从而保证事务原子性。
2. 利用redo log保证事务的持久性，该log关注于事务的恢复。在重启mysql服务的时候，根据redo log进行重做，从而使事务有持久性。
3. 利用undo log+redo log保障一致性。事务中的执行需要redo log，如果执行失败，需要undo log 回滚。

• 集群

• 主从复制

通过binlog完成数据复制，提高可用性，拓展读取能力，数据备份。
其中：

主服务器（Master）：负责处理所有的写操作（INSERT、UPDATE、DELETE等），并将这些操作记录到 Binlog 中。
从服务器（Slave）：从主服务器获取 Binlog，并应用这些日志来保持与主服务器的数据同步。

• 步骤

1. 在master上开启、设置binlog

2. 在master上创建一个复制的用户并授权

3. 在slave上的配置文件中设置

   1 2 3 4 5

   [mysqld] server-id=2 relay-log=mysql-relay-bin log-slave-updates=1 read-only=1

4. 在slave设置主从关系

   1 2 3 4 5 6

   CHANGE MASTER TO MASTER_HOST='master_host', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=12345;

5. 启动slave的I/O线程从master获取binlog事件，启动SQL线程应用binlog事件

• 优缺点

• 优点
  提高可用性，master故障时slave可以转正，数据也能备份
  读写分离，降低master压力

• 缺点
  延迟、数据不一致，master负载大、网络差或者故障的情况下会有binlog同步延迟或者不能同步的问题

• 如何保证主备一致

  主服务器将所有的数据更改操作记录到二进制日志（Binlog）中。
  从服务器通过 I/O 线程从主服务器获取 Binlog，并通过 SQL 线程应用这些日志，从而保持与主服务器的数据一致

1. Go语言使用了哪种垃圾回收算法？

   • Go语言采用了三色标记清除算法，并结合写屏障技术来提高并发性。从Go 1.5开始引入了并发垃圾收集器，之后版本不断优化以减少停顿时间。

2. 解释一下三色标记法的工作原理？

   • 三色标记法将对象分为白色、黑色和灰色三种状态：
     • 白色：表示未访问过的对象。
     • 灰色：表示已经被发现但其引用的对象还未全部检查的对象。
     • 黑色：表示已经完全扫描过且确定为存活的对象。
   • 在GC过程中，所有可达对象最终会被标记为黑色，而仅存的白色对象则被认为是垃圾并被回收。

3. 如何触发垃圾回收？

   • Go语言的GC是自动触发的，基于分配速率和堆大小的增长情况。也可以通过调用runtime.GC()手动触发一次完整的垃圾回收过程。

4. Go语言中的GC是并发的还是串行的？

   • Go语言的GC是并发的，这意味着它可以与应用程序代码同时运行，从而尽量减少对程序执行的影响。不过，在某些阶段仍需要短暂地暂停所有的goroutine（称为”STW”, Stop-The-World），以便安全地完成特定的操作。

5. 什么是写屏障？为什么需要它？

   • 写屏障是在对象之间建立或更新引用时插入的一段辅助代码。它的作用是在并发GC期间确保所有活跃对象都能被正确地标记，即使这些对象正在被修改。

6. GC Roots是什么？
   GC Roots是指那些可以直接访问到的对象集合，

   • 全局变量
   • 活跃的goroutine的栈上的所有引用
   • runtime的部分数据

7. 堆栈上分别会有哪些数据
   栈上：

   • 不会发生逃逸的局部变量

   • 小型且大小固定的结构体、数组

   堆上：

   • make、new创建的对象
   • 大型的数据 大结构体、大数组
   • 切片 map channel，基本信息比如长度、容量、指针可能在栈上，实际的数据会在堆上
   • 逃逸的对象

8. 什么情况会发生逃逸
   局部对象的作用域发生改变、扩散就会发生逃逸

• 函数返回了期内局部变量的指针
• 局部变量被全局变量持有指针
• 局部变量的指针被传递给另外一个goroutine

和 map 相关的操作主要是：

1. 增加一个 k-v 对 —— Add or insert；
2. 删除一个 k-v 对 —— Remove or delete；
3. 修改某个 k 对应的 v —— Reassign；
4. 查询某个 k 对应的 v —— Lookup；

简单说就是最基本的 增删查改。

Go 语言采用的是哈希查找表，并且使用链表解决哈希冲突。

表示 map 的结构体是 hmap

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

每个 bucket 设计成最多只能放 8 个 key-value 对，如果有第 9 个 key-value 落入当前的 bucket，那就需要再构建一个 bucket ，通过 overflow 指针连接起来。

上图中，假定 B = 5，所以 bucket 总数就是 2^5 = 32。首先计算出待查找 key 的哈希，使用低 5 位 00110，找到对应的 6 号 bucket，使用高 8 位 10010111，对应十进制 151，在 6 号 bucket 中寻找 tophash 值（HOB hash）为 151 的 key，找到了 2 号槽位，这样整个查找过程就结束了。

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

扩容

使用哈希表的目的就是要快速查找到目标 key，然而，随着向 map 中添加的 key 越来越多，key 发生碰撞的概率也越来越大。随着向 map 中添加的 key 越来越多，bucket 中的 8 个 cell 会被逐渐塞满，接近退化成链表，各种操作的效率直接降为 O(n)

需要有一个指标来衡量前面描述的情况，这就是装载因子。Go 源码里这样定义 装载因子：

1

loadFactor := count / (2^B)

count 就是 map 的元素个数，2^B 表示 bucket 数量。

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

1. 装载因子超过阈值，源码里定义的阈值是 6.5。
2. overflow 的 bucket 数量过多：当 B 小于 15，也就是 bucket 总数 2^B 小于 2^15 时，如果 overflow 的 bucket 数量超过 2^B；当 B >= 15，也就是 bucket 总数 2^B 大于等于 2^15，如果 overflow 的 bucket 数量超过 2^15。即：
   B<15 cnt(overflow bucket) > cnt(bucket)
   B>=15 cnt(overflow bucket) > 2^15

for case 1: 平均每个 bucket 中存放了超过6.5个 kv
for case 2: 本质上是 key 的 hash 特征趋同
1 多次循环 插入大量但未达到 case 1 的元素，然后删除其中部分元素，致使出现了 大量 overflow bucket, 即 kv 不多，但 overflow bucket 很多
2 就是 key 的 hash 特征恰好一致，未达到分流的效果(此时golang的扩容策略无效 因为问题不是容量的问题 是hash算法的问题 应该无解 或者做丑陋的patch)

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

对于条件 1，元素太多，而 bucket 数量太少，将 B 加 1 ：
bucket 最大数量（2^B）直接变成原来 bucket 数量的 2 倍。就没这么简单了。要重新计算 key 的哈希，才能决定它到底落在哪个 bucket。例如，原来 B = 5，计算出 key 的哈希后，只用看它的低 5 位，就能决定它落在哪个 bucket。扩容后，B 变成了 6，因此需要多看一位，它的低 6 位决定 key 落在哪个 bucket。这称为 rehash。

对于条件 2，元素没那么多，但是 overflow bucket 数特别多，说明很多 bucket 都没装满。解决办法就是开辟一个新 bucket 空间，将老 bucket 中的元素移动到新 bucket，使得同一个 bucket 中的 key 排列地更紧密。这样，原来，在 overflow bucket 中的 key 可以移动到 bucket 中来。结果是节省空间，提高 bucket 利用率，map 的查找和插入效率自然就会提升。
从老的 buckets 搬迁到新的 buckets，由于 bucktes 数量不变，因此可以按序号来搬，比如原来在 0 号 bucktes，到新的地方后，仍然放在 0 号 buckets。

在搬迁过程中，oldbuckets 指针还会指向原来老的 []bmap，并且已经搬迁完毕的 key 的 tophash 值会是一个状态值，表示 key 的搬迁去向。

在插入、修改、删除 key 以及遍历的时候，都会尝试进行搬迁 buckets 的工作。先检查 oldbuckets 是否搬迁完毕，具体来说就是检查 oldbuckets 是否为 nil。

遍历

遍历所有的 bucket 以及它后面挂的 overflow bucket，然后挨个遍历 bucket 中的所有 cell。每个 bucket 中包含 8 个 cell，从有 key 的 cell 中取出 key 和 value。

开始在哪个 bucket 以及在 bucket 中哪个 cell 开始遍历是通过生成随机数 然后进行位运算决定的

插入

对 key 计算 hash 值，根据 hash 值按照之前的流程，找到要赋值的位置（可能是插入新 key，也可能是更新老 key）

删除

删除操作同样是两层循环，核心还是找到 key 的具体位置。寻找过程都是类似的，在 bucket 中挨个 cell 寻找，找到对应位置后，对 key 或者 value 进行“清零”，最后，将 count 值减 1，将对应位置的 tophash 值置成 Empty

float 类型作为key

float 类型可以作为 map 的 key ，当用 float64 作为 key 的时候，先要将其转成 uint64 类型，再插入 key 中。但是由于精度的问题，会导致一些诡异的问题，慎用之。

线程安全

• 边遍历边删除，遍历的结果就可能不会是相同的了，有可能结果遍历结果集中包含了删除的 key，也有可能不包含，这取决于删除 key 的时间：是在遍历到 key 所在的 bucket 时刻前或者后
• 多协程并发写 会触发 concurrent map writes
• 多协程并发读写 会触发 concurrent map read and map write
• 多协程并发遍历/写 会触发 concurrent map iteration and map write

ref

go-questions: map

预期元素应该为:
<img src="/img/assets.avif" alt="Terraform deployment workflow">
但实际是
<img src="/.io//assets.avif" alt="Terraform deployment workflow">

hexo版本配置信息如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

INFO  Validating config
hexo: 7.2.0
hexo-cli: 4.3.2
os: darwin 23.5.0 14.5

node: 20.5.1
acorn: 8.10.0
ada: 2.5.1
ares: 1.19.1
base64: 0.5.0
brotli: 1.0.9
cjs_module_lexer: 1.2.2
cldr: 43.1
icu: 73.2
llhttp: 8.1.1
modules: 115
napi: 9
nghttp2: 1.55.1
openssl: 3.1.2
simdutf: 3.2.14
tz: 2023c
undici: 5.22.1
unicode: 15.0
uv: 1.46.0
uvwasi: 0.0.18
v8: 11.3.244.8-node.10
zlib: 1.2.11

根据网上线索，修改hexo的\node_modules\hexo-asset-image\index.js 26行。
原：
link = link.substring(beginPos, endPos) + '/' + appendLink;
改为(根据自己情况)：
link = 'img/' + appendLink;

经过 hexo g 后生成的图像元素即与预期元素
<img src="/img/assets.avif" alt="Terraform deployment workflow">
相同。

维基百科里这样定义 map：

In computer science, an associative array, map, symbol table, or dictionary is an abstract data type composed of a collection of (key, value) pairs, such that each possible key appears at most once in the collection.

• 算法基础

在golang中，map的实现主要是基于hash算法。而hash算法常常会出现碰撞的问题，一般有两种方式进行应对，一是链表地址(golang就采用了此方式)，再就是开放寻址法。

• hash表(单向散列表)

通过建立key与elem的映射，达到高效查找key对应的elem，一般时间复杂度为O(1)。
举个简单的例子：

仅用一个数组来实现哈希表。在哈希表中，我们将数组中的每个空位称为桶（bucket），每个桶可存储一个键值对。因此，查询操作就是找到 key 对应的桶，并在桶中获取 value 。
那么，如何基于 key 定位对应的桶呢？这是通过哈希函数（hash function）实现的。哈希函数的作用是将一个较大的输入空间映射到一个较小的输出空间
输入一个 key ，哈希函数的计算过程分为以下两步。

1. 通过某种哈希算法 hash() 计算得到哈希值。

2. 将哈希值对桶数量（数组长度）capacity 取模，从而获取该 key 对应的数组索引 index 。
   index = hash(key) % capacity

随后，我们就可以利用 index 在哈希表中访问对应的桶，从而获取 value 。

设数组长度 capacity = 100、哈希算法 hash(key) = key ，易得哈希函数为 key % 100 。

• hash冲突

从本质上看，哈希函数的作用是将所有 key 构成的输入空间映射到数组所有索引构成的输出空间，而输入空间往往远大于输出空间。因此，理论上一定存在“多个输入对应相同输出”的情况。
对于上述示例中的哈希函数，当输入的 key 后两位相同时，哈希函数的输出结果也相同。例如，查询学号为 12836 和 20336 的两个学生时，我们得到：

1
2

12836 % 100 = 36
20336 % 100 = 36

两个学号指向了同一个姓名，这显然是不对的。我们将这种多个输入对应同一输出的情况称为哈希冲突（hash collision）

解决hash冲突有两种方法

1. 链式地址
   在原始哈希表中，每个桶仅能存储一个键值对。链式地址（separate chaining）将单个元素转换为链表，将键值对作为链表节点，将所有发生冲突的键值对都存储在同一链表中。
   
   基于链式地址实现的哈希表的操作方法发生了以下变化。

• 查询元素：输入 key ，经过哈希函数得到桶索引，即可访问链表头节点，然后遍历链表并对比 key 以查找目标键值对。
• 添加元素：首先通过哈希函数访问链表头节点，然后将节点（键值对）添加到链表中。
• 删除元素：根据哈希函数的结果访问链表头部，接着遍历链表以查找目标节点并将其删除。
  链式地址存在以下局限性。
• 占用空间增大：链表包含节点指针，它相比数组更加耗费内存空间。
• 查询效率降低：因为需要线性遍历链表来查找对应元素。
  值得注意的是，当链表很长时，查询效率 $O(n)$ 很差。此时可以将链表转换为“AVL 树”或“红黑树”，从而将查询操作的时间复杂度优化至 $O(\log n)$ 。

2. 开放寻址
   开放寻址（open addressing）不引入额外的数据结构，而是通过“多次探测”来处理哈希冲突，探测方式主要包括线性探测、平方探测和多次哈希等。
   下面以线性探测为例，介绍开放寻址哈希表的工作机制。
   线性探测采用固定步长的线性搜索来进行探测，其操作方法与普通哈希表有所不同。

• 插入元素：通过哈希函数计算桶索引，若发现桶内已有元素，则从冲突位置向后线性遍历（步长通常为 $1$ ），直至找到空桶，将元素插入其中。
• 查找元素：若发现哈希冲突，则使用相同步长向后进行线性遍历，直到找到对应元素，返回 value 即可；如果遇到空桶，说明目标元素不在哈希表中，返回 None 。
  下图展示了开放寻址（线性探测）哈希表的键值对分布。根据此哈希函数，最后两位相同的 key 都会被映射到相同的桶。而通过线性探测，它们被依次存储在该桶以及之下的桶中。
  
  然而，线性探测容易产生“聚集现象”。具体来说，数组中连续被占用的位置越长，这些连续位置发生哈希冲突的可能性越大，从而进一步促使该位置的聚堆生长，形成恶性循环，最终导致增删查改操作效率劣化。
  值得注意的是，我们不能在开放寻址哈希表中直接删除元素。这是因为删除元素会在数组内产生一个空桶 None ，而当查询元素时，线性探测到该空桶就会返回，因此在该空桶之下的元素都无法再被访问到，程序可能误判这些元素不存在.
  为了解决该问题，我们可以采用懒删除（lazy deletion）机制：它不直接从哈希表中移除元素，而是利用一个常量 TOMBSTONE 来标记这个桶。在该机制下，None 和 TOMBSTONE 都代表空桶，都可以放置键值对。但不同的是，线性探测到 TOMBSTONE 时应该继续遍历，因为其之下可能还存在键值对。
  然而，懒删除可能会加速哈希表的性能退化。这是因为每次删除操作都会产生一个删除标记，随着 TOMBSTONE 的增加，搜索时间也会增加，因为线性探测可能需要跳过多个 TOMBSTONE 才能找到目标元素。
  为此，考虑在线性探测中记录遇到的首个 TOMBSTONE 的索引，并将搜索到的目标元素与该 TOMBSTONE 交换位置。这样做的好处是当每次查询或添加元素时，元素会被移动至距离理想位置（探测起始点）更近的桶，从而优化查询效率。

容易想到，哈希表容量越大，多个 key 被分配到同一个桶中的概率就越低，冲突就越少。因此，我们可以通过扩容哈希表来减少哈希冲突。

• hash扩容

类似于数组扩容，哈希表扩容需将所有键值对从原哈希表迁移至新哈希表，非常耗时；并且由于哈希表容量 capacity 改变，我们需要通过哈希函数来重新计算所有键值对的存储位置，这进一步增加了扩容过程的计算开销。为此，编程语言通常会预留足够大的哈希表容量，防止频繁扩容。
负载因子（load factor）是哈希表的一个重要概念，其定义为哈希表的元素数量除以桶数量，用于衡量哈希冲突的严重程度，也常作为哈希表扩容的触发条件。例如在 golang 中，当负载因子超过 $0.65$ 时，系统会将哈希表扩容至原先的 $2$ 倍。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

func question(cnt int) {
runtime.GOMAXPROCS(1)

var wg sync.WaitGroup

for i := 1; i <= cnt; i++ {
wg.Add(1)
go func(n int) {
defer wg.Done()
println(n)
}(i)
}

wg.Wait()
}

给出不同范围的cnt的输出是什么

当 cnt 小于等于 257 时，输出为序列

1
2
3
4
5
6

cnt
1
2
3
...
cnt-1

当 cnt 大于等于 258 时，输出为

1
2
3
4
5
6
7
8
9
10

cnt
*
...
1
*
...
*
...
2
...

首先，解释为什么第一个一般都是cnt, 在循环中cnt最后一个被加入到协程队列中，其实会被加到runnext中，在协程队列中第一个会执行runnext，然后会从本地runq中取协程，但是本地队列中一旦加入超过256个协程，就会切出128个到全局runq中，如此往复。同时每当本地runq执行了61次后就会从全局runq中获取一个进行执行，主要是防止全局runq中的协程被饿死。于是就会有如上输出。

长轮询是一种模拟HTTP上服务器推送的技术，通过保持连接打开状态直到有新数据可用来减少不必要的网络流量。

• WebSocket

WebSocket提供了一个全双工的、长期存在的连接通道，适合需要低延迟的应用场景，如实时聊天、游戏和金融交易平台。

• 服务器发送事件（Server-Sent Events, SSE）

服务器发送事件（Server-Sent Events, SSE）是一种从服务器单向推送更新到客户端的简单方法，适用于只需要服务器更新的场景，如实时新闻源、体育比分或需要实时更新的情况。SSE在连接断开时会自动重连，管理起来比WebSocket更简单。

• WebTransport

WebTransport是一个基于HTTP/3 QUIC协议的新兴API，旨在实现高效、低延迟的客户端和服务器通信。它支持多流传输、可靠和不可靠的数据以及乱序发送数据，适用于高性能应用，如实时游戏和流媒体。然而，WebTransport目前仍处于工作草案阶段，支持度不广。

• WebRTC

WebRTC是一个用于浏览器和移动应用之间实时通信的开源项目，支持音频、视频和数据的点对点交换，但不直接与上述技术相比较，因为它主要用于客户端之间的交互，而非服务器客户端通信。

• 限制

• 基础限制

1. 只有WebSocket和WebTransport支持双向通信。
2. 长轮询理论上可以双向通信，但不推荐，因为发送新数据到现有的长轮询连接会需要额外的HTTP请求。
3. SSE不支持向服务器发送数据，只能接收服务器的初始请求，且通常不能在HTTP正文中发送POST数据，但可以使用一些库（如eventsource polyfill）来扩展其功能。

• 浏览器的连接限制：
  大多数现代浏览器每个域名允许六个连接，这限制了持续服务器到客户端消息传递方法的使用。尽管可以通过使用HTTP/2或HTTP/3来解决，这些协议使用单一连接并利用多路复用技术，但仍有默认的最大并发流设置（通常是100个并发流）。
  在移动应用中，操作系统可能会关闭后台应用的开放连接，导致WebSocket等技术难以维持。在这种情况下，通常使用移动推送通知来更有效地发送数据。
  企业环境中的代理和防火墙可能阻止非HTTP连接，使得WebSocket等技术难以集成，而SSE使用标准HTTP请求，可能更容易适应这些环境。

• 性能对比

WebSocket、SSE和WebTransport在低延迟、高吞吐量和可扩展性方面表现相似，但WebTransport依赖于新的HTTP/3协议，未来可能会有更多性能优化。
长轮询在延迟和吞吐量方面较差，因为它依赖于频繁建立新的HTTP连接。

• 场景

1. SSE适合需要频繁服务器到客户端更新的简单场景，如新闻提要和实时数据流。
2. WebSocket适用于需要持续双向通信的应用，如游戏和聊天应用。
3. WebTransport是未来的趋势，但目前支持度不足，适用于需要高效多流通信的场景。
4. 长轮询现在已被其他技术取代，不建议作为首选方案。

在构建实时应用程序时，应考虑这些技术的局限性和适用场景，并确保处理可能的连接问题，如客户端重新连接时可能错过的事件，以及公司网络环境中可能遇到的代理和防火墙问题。

ref：

WebSockets vs Server-Sent-Events vs Long-Polling vs WebRTC vs WebTransport

1. 创建仓库

创建一个github仓库，根据自己的情况选择公开或者私有，再根据功能范围起一个库名。

2. 初始化

将项目拉到本地，

1

go mod init <你的库名>

3. 添加库功能

把需要发布的功能函数添加到项目中，其中不希望被引用的功能，可以放到项目下internal/路径中

4. push

将变更完的项目推送到github

5. 引用

在其他项目中，执行

1

go get -v github.com/<你的github用户名>/<你的库名>

然后就结束啦！

1
2
3
4
5
6
7
8
9
10

[root@localhost testPlc]# ./ready.o 
0       02
1       30
2       30
3       46
4       46
5       31
6       03
7       32
8       bd

按照通信协议，串口应返回的的是

1
2
3
4
5
6
7
8
9
10

0       02
1       30
2       30
3       46
4       46
5       31
6       03
7       32
8       31
9       38

并且其他几个指令，也是与通信协议所要求的返回的位数不同，并且最后一位也有是错误的，使用串口助手有没有问题。所以推测是接收区只有8位，然后代码里的接收buffer设置为128，所以应该是底层的原因，所以采用了select进行等待，最终实现了完整读取串口信息
代码示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

void SetBench(unsigned char *msg, unsigned char *recv) {
    fd_set fs_read;
    int fd = nFd;
//nFd是串口句柄
    unsigned char buf[16] = {0};

    struct timeval time;
    FD_ZERO(&fs_read);
    FD_SET(fd, &fs_read);

    time.tv_sec = 2;
    time.tv_usec = 0;
    write(fd, msg, strlen(msg));

    while (select(fd + 1, &fs_read, NULL, NULL, &time) > 0) {
        len = read(fd, buf, sizeof(recv));
        if (8 == len) {
            strncpy(recv + count, buf, 8);
            count += 8;
        }
        if (len > 0 && len < 8) {
            strncpy(recv + count, buf, len);
            count += len;
        }
    }
}

1

sed -i -e "s/$ori/$curr/g" $CONF

报错 sed: -e expression #1, char 0: no previous regular expression

是因为 $ori 为空