注意 `Cap` 也是底层数组的长度。`Data` 是一块连续的内存，可以存储切片 `Cap` 大小的所有元素。

如图，虽然 slice 的 `Len` 是 5，但是底层数组的长度是 10，也就是 `Cap`。

- `s1 := slice[2:5]` 得到的 `s1` 的容量为 8，因为没有传入 `max`，容量默认是到底层数组的结尾。

- `s2 := s1[2:6:7]` 得到的 `s2` 的容量为 5（`max - low`）。`s2`，`s1` 和 `slice` 底层数组是同一个，所以 `s2` 中的元素是 `[4,5,6,7]`。

下面的 `s2 = append(s2, 100)` 追加一个元素，容量够用，不需要扩容，但是这个修改会影响所有指向这个底层数组的切片。

再次追加一个元素 `s2 = append(s2, 200)`，`s2` 的容量不够了，需要扩容，于是 `s2` 申请一块新的连续内存，并将数据拷贝过去，扩容后的容量是原来的 2 倍。

这时候 `s2` 的 `Data` 指向了新的底层数组，已经和 `s1` `slice` 没有关系了，对 `s2` 的修改不会再影响 `s1` `slice`。

最后 `s1[2] = 20` 也不会再影响 `s2`。

哈希表是通过**哈希函数**将 key 转化为数组的下标，然后将数据存储在数组下标对应的位置。查询时，也是同样的使用哈希函数计算出数组下标，从下标对应的位置取出数据。

哈希函数的基本要求：

开放寻址法核心思想是，如果出现了哈希冲突，就重新探测一个空闲位置，将其插入。

上图蓝色表示已经插入的元素，`key9` 哈希后得到的数组下标为 6，但是已经有数据了，产生了冲突。那么就按顺序向后查找直到找到一个空闲的位置，如果到数组的尾部都没有找到空闲的位置，就从头开始继续找。

上图最终找到位置 1 并插入元素。

链表法是最常见的哈希冲突的解决办法。在哈希表中，每个桶（bucket）会对应一条链表，所有哈希值相同的元素都放到相同桶对应的链表中。

插入时，哈希函数计算后得出存放在几号桶，然后遍历桶中的链表了：

`bmap` 就是桶，一个桶里面会最多存储 8 个键值对。

1. 在桶内，会根据 key 计算出来的 hash 值的高 8 位来决定 key 存储在桶中的位置。

2. key 和 value 是分别放在一块连续的内存，这样做的目的是为了节省内存。例如一个 `map[int64]int8` 类型的 map，如果按照 `key1/value1/key2/value2 ...` 这样的形式来存储，那么内存对齐每个 `key/value` 都需要 padding 7 个字节。

分开连续存储的话，就只需要在最后 padding 一次。

3. 每个桶只能存储 8 个 `key/value`，如果有更多的 key 放入当前桶，就需要一个溢出桶，通过 `overflow` 指针连接起来。

查询过程：

例如，原来 `B=5`，根据出 key 的哈希值的后 5 位，就能决定它落在哪个 bucket。扩容后的 buckets 数量翻倍，B 变成了 6，因此变成哈希值的后 6 位才能决定 key 落在哪个 bucket。这叫做 `rehash`。

因此，某个 key 在迁移前后 bucket 序号可能会改变，取决于 `rehash` 之后的哈希值倒数第 6 位是 0 还是 1。

- 任何类型的指针 `*T` 可以和 `unsafe.Pointer` 相互转换。

- `uintptr` 可以和 `unsafe.Pointer` 相互转换。

指针类型转换示例：

`state` 是一个复合型的字段，包含多个意义：

在默认状态下，互斥锁的所有状态位都是 0，`int32` 中的不同位分别表示了不同的状态：

`state1` 包含一个总共占用 12 字节的数组，这个数组会存储当前结构体的状态，在 64 位与 32 位的机器上表现也非常不同。

`state` 方法用来从 `state1` 字段中取出它的状态和信号量。

例如，Go 的 HTTP server，处理每一个请求，都是启动一个单独的 goroutine，处理过程中还会启动新的 goroutine 来访问数据库和其他服务。而 context 在不同 Goroutine 之间可以同步请求特定数据、取消信号以及处理

请求的截止日期。

每一个 context 都会从 root goroutine 一层层传递到底层。context 可以在上层 goroutine 执行出现错误时，将信号及时同步给下层。

打开 http://localhost:8080/debug/pprof 后会看到下面页面：

pprof 包括了几个子页面：

> 如果出现 `Could not execute dot; may need to install graphviz.`，那么需要安裝 Graphviz。

图中框越大，线越粗代表它占用 CPU 的时间越长。

点击 `View -> Flame Graph` 可以查看火焰图：

图中调用顺序由上到下，每一块代表一个函数，越大代表占用 CPU 的时间越长。

访问 http://127.0.0.1:59181，可以看到类似的界面：

- `View trace`：查看所有 goroutines 的执行过程。

- `Goroutine analysis`：goroutines 分析，查看具体的 goroutine 的信息。

进入 `View trace` 页面：

1. 时间线：显示执行的时间。

2. Goroutines/Heap/Threads 的详细信息。

图中正在运行的 goroutine 数量为 3，其他状态的 goroutine 数量都是 0。

1. 红色部分表示已经占用的内存

2. 绿色部分的上边沿表示下次 GC 的目标内存，也就是绿色部分用完之后，就会触发 GC。

图中正在运行的线程数量为 3，正在调用 SysCall 的线程数量为 0。

可以选择多个查看统计信息。

点击具体的 Goroutine 可以查看详细信息：

进入 `Goroutine analysis` 可查看整个运行过程中，每个函数块有多少个 goroutine 在跑，并且观察每个的 goroutine 的运行开销都花费在哪个阶段。

点击一个 goroutine 查看详细信息，例如 `main.main.func1`：

| 名称 | 含义 | 耗时 |

|-----------------------|--------|-------|

进行内存对齐，就是为了减少 CPU 访问内存的次数。

上图中，假如 CPU 字长为 4 个字节。变量 a 和 b 的大小为 3 个字节，没有内存对齐之前，CPU 读取 b 时，需要访问两次内存：

`Part1` 只是对成员变量的字段顺序进行了调整，就减少了结构体占用大小。

`part1`：