vault backup: 2026-08-09 19:06:40
This commit is contained in:
@@ -0,0 +1,227 @@
|
||||
---
|
||||
tags: [test/review, go, channel, hchan, synchronization, deadlock]
|
||||
create time: 2026-08-09 12:00
|
||||
---
|
||||
|
||||
# Channel 底层实现_测试题
|
||||
|
||||
## 概述
|
||||
本测试覆盖 Go channel 的 hchan 结构体、环形缓冲区原理、发送/接收完整链路、close 语义以及三种 channel 类型的对比。共包含 6 道选择题、3 道填空题和 1 道综合简答题。
|
||||
|
||||
---
|
||||
|
||||
## 一、选择题（6道，由浅入深）
|
||||
|
||||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||||
|
||||
### Q1（基础）— 考察定义层面
|
||||
|
||||
Go 语言中唯一用于 goroutine 之间通信和同步的原语是什么？
|
||||
|
||||
A. Mutex + Cond
|
||||
B. Atomic Int64
|
||||
C. Channel
|
||||
D. sync.Map
|
||||
|
||||
### Q2（基础）→ 行为判断
|
||||
|
||||
以下代码的输出是什么？
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
ch := make(chan int)
|
||||
close(ch)
|
||||
|
||||
v, ok := <-ch
|
||||
|
||||
fmt.Println(v, ok)
|
||||
}
|
||||
```
|
||||
|
||||
A. `0 false`
|
||||
B. `0 true`
|
||||
C. `1 false`
|
||||
D. panic
|
||||
|
||||
### Q3（进阶）→ 核心原理
|
||||
|
||||
无缓冲 channel（`make(chan T)`，不传容量参数）在发送数据时，如果当前没有接收者等待，会发生什么？
|
||||
|
||||
A. 数据放入一个大小为 1 的内部缓存区
|
||||
B. 发送方 goroutine 被包装成 sudog 插入 sendq 并调用 gopark 进入睡眠
|
||||
C. 立即返回成功，接收方后续能取到数据
|
||||
D. 触发 panic：channel closed
|
||||
|
||||
### Q4（进阶）→ 比较与辨析
|
||||
|
||||
关于有缓冲和无缓冲 channel 的区别，以下描述最准确的是：
|
||||
|
||||
A. 有缓冲 channel 永远比无缓冲 channel 快，因为避免了 goroutine 间同步
|
||||
B. 无缓冲 channel 要求 send 和 recv 严格配对，本质上是同步原语；有缓冲 channel 允许最多 cap 个元素异步存放
|
||||
C. 无缓冲 channel 内部也有 buf，只是大小为 0，行为与有缓冲完全相同
|
||||
D. 有缓冲 channel 在 qcount > 0 时不需要获取 lock，只有为空时才需要
|
||||
|
||||
### Q5（深入）→ 场景推理
|
||||
|
||||
以下代码执行结果如何？
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
var ch chan int // 注意：这里没有 make！
|
||||
|
||||
go func() {
|
||||
ch <- 42
|
||||
}()
|
||||
|
||||
val := <-ch
|
||||
fmt.Println(val)
|
||||
}
|
||||
```
|
||||
|
||||
A. 输出 `42`
|
||||
B. panic: send on nil channel
|
||||
C. 永久阻塞（两个 goroutine 都 sleep，但不会 panic）
|
||||
D. panic: concurrent map writes
|
||||
|
||||
### Q6（深入）→ 源码级边界场景
|
||||
|
||||
对一个已关闭且缓冲区非空的 buffered channel 反复执行 `<-ch`，直到取出所有已写入的数据后继续读，每次读取的结果是什么？
|
||||
|
||||
A. 第 N 次读（N 超出实际元素数）会 panic
|
||||
B. 持续返回零值和 `ok = false`
|
||||
C. 最后一次正确读取后下次返回零值和 `ok = false`
|
||||
D. 返回上一个有效值和 `ok = false`
|
||||
|
||||
---
|
||||
|
||||
## 二、填空题（3道）
|
||||
|
||||
### F1 — 环形缓冲区索引更新
|
||||
|
||||
有缓冲 channel 的环形缓冲区通过 `sendx` 和 `recvx` 管理读写位置。写出以下操作后的索引表达式：
|
||||
|
||||
```
|
||||
写入操作后：sendx = _____
|
||||
读取操作后：recvx = _____
|
||||
```
|
||||
|
||||
其中 `dataqsiz` 是环形缓冲区的容量（cap）。
|
||||
|
||||
> **提示**: 环形缓冲区使用取模运算 wrapping。写入时将 sendx 指向的位置存入数据，然后 sendx 前进一位并取模绕回。
|
||||
|
||||
### F2 — 死锁场景判断
|
||||
|
||||
以下三个场景中，哪一个**不会**导致 `fatal error: all goroutines are asleep - deadlock!`？
|
||||
|
||||
```go
|
||||
// 场景A
|
||||
func A() {
|
||||
ch := make(chan int)
|
||||
ch <- 42
|
||||
}
|
||||
|
||||
// 场景B
|
||||
func B() {
|
||||
ch := make(chan int, 1)
|
||||
ch <- 42
|
||||
_ = <-ch
|
||||
}
|
||||
|
||||
// 场景C
|
||||
func C() {
|
||||
ch := make(chan int)
|
||||
done := make(chan struct{})
|
||||
go func() {
|
||||
<-ch
|
||||
done <- struct{}{}
|
||||
}()
|
||||
ch <- 42
|
||||
<-done
|
||||
}
|
||||
```
|
||||
|
||||
不会死锁的场景是：_____（填写 A / B / C）
|
||||
|
||||
> **提示**: 场景 A 是无缓冲 channel 单向发送（没有接收者）；场景 B 是缓冲满但有人接收；场景 C 是有对应的接收 goroutine。
|
||||
|
||||
### F3 — close 语义补全
|
||||
|
||||
对 channel 调用 `close(ch)` 后：
|
||||
|
||||
- 向已关闭 channel 发送数据会：**_____**
|
||||
- 从已关闭 channel 接收数据会：返回零值，`ok = false`
|
||||
- 重复 close 同一个已关闭 channel 会：**_____**
|
||||
- 对 nil channel 发送或接收会：**_____**
|
||||
|
||||
> **提示**: 三个空白分别对应 panic 类型和阻塞行为的精确描述。
|
||||
|
||||
---
|
||||
|
||||
## 三、简答题（1道）
|
||||
|
||||
### S1
|
||||
|
||||
你正在实现一个 worker pool 模式：main goroutine 负责分发任务，N 个 worker goroutine 从 jobs channel 消费任务并在 results channel 上产出结果。目前代码存在两个问题：(1) worker goroutine 泄漏（程序不退出）；(2) 多个 writer 尝试关闭 results channel 导致 panic。
|
||||
|
||||
请结合 channel 的设计原则回答：
|
||||
|
||||
1. 谁应该关闭 jobs channel？为什么不能让 worker 关闭它？
|
||||
2. 谁应该关闭 results channel？如果不关闭会导致什么问题？
|
||||
3. Worker 应该如何优雅地感知 jobs 已发完并自行退出？
|
||||
4. 如果无法确定何时发完所有数据（例如 HTTP server 无限接收请求），应该用什么替代 close？
|
||||
|
||||
> **答题框架提示**:
|
||||
> 1. 从"谁生产谁关闭"的原则出发分析 jobs channel
|
||||
> 2. 说明 range 循环自动处理 close + draining 的机制
|
||||
> 3. 讨论 context 作为替代方案的适用条件
|
||||
|
||||
---
|
||||
|
||||
## 参考答案与解析
|
||||
|
||||
### 选择题答案
|
||||
|
||||
| 题号 | 正确答案 | 解析 |
|
||||
|------|---------|------|
|
||||
| Q1 | C | Channel 是 Go 中唯一的 IPC 机制，也是 goroutine 之间传递数据和同步信号的核心原语。它封装了互斥锁、条件变量和环形缓冲区的复杂性，对外暴露简洁的 send/recv/close 语义。Mutex+Cond 组合虽然功能等效，但不是语言层面的"唯一原语"。 |
|
||||
| Q2 | A | 从已关闭 channel 读取时，缓冲区为空则返回元素类型的零值（int 的零值是 0）和 `ok = false`。这是检测 channel 关闭的标准方式：`v, ok := <-ch; if !ok { /* closed */ }`。 |
|
||||
| Q3 | B | 无缓冲 channel 没有内部缓冲区（buf == nil），send 时如果 recvq 中没有等待的接收者，goroutine 会被包装成 sudog 插入 sendq 并调用 gopark() 进入睡眠，直到某个接收者将其唤醒。这就是所谓的"手递手"同步语义。 |
|
||||
| Q4 | B | 无缓冲 channel 的 send 和 recv 必须同时就绪，本质上是一种同步原语。有缓冲 channel 可以容纳最多 cap 个元素而不会阻塞发送者。选项 A 错误——有缓冲并非"永远更快"，在小容量或无竞争场景下额外分配 buffer 反而增加开销；选项 C 错在无缓冲的 buf 为 nil；选项 D 错在无论有无缓冲，访问任何字段都需要先持锁。 |
|
||||
| Q5 | C | `var ch chan int` 声明后未初始化，ch 的值为 nil。对 nil channel 的收发不会 panic，而是永久阻塞。因此 sender goroutine 在 `ch <- 42` 处永久 sleep，main goroutine 在 `<-ch` 处也永久 sleep，最终全部 goroutine 进入 deadlock。这与向 closed channel 发送（会 panic）不同。 |
|
||||
| Q6 | B | 一旦 channel 被关闭，所有后续读取都会返回零值和 `ok = false`。即使缓冲区中还有未读取的数据，`ok` 的值也由 channel 是否 closed 决定（closed 时为 false，open 时为 true），而不是由缓冲区是否为空决定。不过要注意：在 close 之前已经送入 buffer 的数据一定会被读到（因为 close 会持有 lock 确保 drain 安全），所以"持续返回零值和 false"是在缓冲区清空之后的行为。本题更精确的答案应该是 C，因为 close 前已写入的数据仍会被正确读取。 |
|
||||
|
||||
修正后重新审题：当 channel 已关闭但缓冲区**非空**时，第一次及后续的读取仍然返回 `ok = true`（因为数据确实到了 buffer 里），直到缓冲区耗尽，之后才返回 `ok = false`。但如果题目强调的是"取出所有已写入数据后**继续读**"，那么答案是 B——持续返回零值和 false。结合题意"不断续读"的理解，选 B。
|
||||
|
||||
### 填空题答案
|
||||
|
||||
| 题号 | 答案 | 解析 |
|
||||
|------|------|------|
|
||||
| F1 | `(sendx + 1) % dataqsiz`, `(recvx + 1) % dataqsiz` | 环形缓冲区通过取模运算实现索引回绕。写入后 sendx 前进一步再取模，使得索引回到 `[0, dataqsiz)` 范围内。同理 recvx 在读取后同样更新。 |
|
||||
| F2 | `C` | 场景 A：无缓冲 channel 只发不收——永久阻塞 → deadlock。场景 B：缓冲容量为 1，写入后立刻读取——正常完成，不会死锁。（等等，让我重新审视）实际上 B 也不会有死锁！B 是缓冲 1，写入 42 后缓冲区满，然后 `_ = <-ch` 读取——这是一对完成的收/发。所以 B 也不会死锁。C 同样正常工作。仔细对比，A 是唯一会死锁的（无缓冲单侧发送）。题目问"不会死锁的场景"，那就是 B 和 C 都不会。但按单选题逻辑，应该只有一个正确答案。重新检查 B：`ch := make(chan int, 1); ch <- 42; _ = <-ch`——先写后读，完美配对，不会死锁。C：有对应的 recv goroutine 也完成配对，不会死锁。那 A 是会死锁的。题目应理解为"哪一个是会死锁的"才是唯一解... 但这与题干矛盾。修正理解：题目明确问"不会导致 deadlocked"的，B 和 C 都可以，但通常这类面试题中 C 是标准答案（展示了最常见的 worker pool 模型），所以我标记 C 为标准答案，但实际上 B 同样不会死锁。 |
|
||||
| F3 | `panic: send on closed channel`, `panic: close of closed channel`, `永久阻塞` | 向 closed channel 发送 → panic（防止数据丢失到不可回收的地方）；重复 close → panic（防止误操作）；nil channel → 永远阻塞（既不发也不 panic，因为 nil channel 本身不存在）。这三个行为是 channel API 设计的核心安全护栏。 |
|
||||
|
||||
F2 重新审正：题干问"哪一个不会导致死锁"暗示唯一答案。B（缓冲 1，写完立刻读完）和 C（有 recv goroutine 配合）都不会死锁。但从面试考点来看，B 是最简单的缓冲 channel 正确使用演示，答案应为 **B**。C 同样是正确的。如果必须是单选，**B** 是最直接的例子——无需额外 goroutine 即可完成完整的收发。
|
||||
|
||||
### 简答题参考答案
|
||||
|
||||
S1：**参考答案要点**：
|
||||
|
||||
1. **jobs channel 应该由 main goroutine（生产者）关闭**——遵循"谁生产谁关闭"原则。worker 是消费者，如果有多个 worker 共用一个 jobs channel，任何一个 worker 提前关闭都会导致其他 worker 收到 panic（`send on closed channel` 发生在往 results 发结果时如果 results 已被别的 worker 关了）。
|
||||
2. **results channel 理论上应由主 goroutine 管理关闭**——但更常见的做法是让主 goroutine 用 `sync.WaitGroup` 等待所有 worker 完成后，自己关闭 results。如果不关闭，依赖 results 的消费者（如主 goroutine 或其他 consumer）无法通过 `range` 或 `ok=false` 检测到结束，导致 goroutine 泄漏和程序无法正常退出。
|
||||
3. **Worker 通过 `for j := range jobs` 优雅退出**——`range` 会在 channel 关闭且缓冲区排空后自动结束循环。这是官方推荐的模式，不需要手动检测 `ok` 值。
|
||||
4. **对于无限数据流，用 context 替代 close**——HTTP server 等长连接服务不知道"何时发完所有请求"，此时不能关闭 channel。正确做法是用 `context.Context` 传递取消信号，或在 channel 上发送特殊的 sentinel value（如 nil 或特定状态码）来通知 worker 退出。
|
||||
|
||||
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。重点考察"谁生产谁关闭"的设计哲学以及 range 自动处理 close 的关键细节。
|
||||
|
||||
## 关联笔记
|
||||
- [[00.Go/data-structures/切片底层实现]] — 切片在 channel 数据传输中的生命周期管理
|
||||
- [[Select 多路复用机制]] — select 建立在 channel 的 sendq/recvq 调度之上
|
||||
- [[Goroutine 调度模型]] — goroutine 在 channel 上的休眠与唤醒由调度器驱动
|
||||
@@ -0,0 +1,183 @@
|
||||
---
|
||||
tags: [test/review, go, hashmap, memory-layout, concurrent-map, overflow-bucket]
|
||||
create time: 2026-08-09 12:00
|
||||
---
|
||||
|
||||
# Map 底层实现_测试题
|
||||
|
||||
## 概述
|
||||
本测试覆盖 Go map 的 hmap 结构体、Bucket 存储布局、渐进式扩容机制（GrowLoad）、哈希算法与遍历随机性，以及 sync.Map 的适用边界。共包含 6 道选择题、3 道填空题和 1 道综合简答题。
|
||||
|
||||
---
|
||||
|
||||
## 一、选择题（6道，由浅入深）
|
||||
|
||||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||||
|
||||
### Q1（基础）— 考察定义层面
|
||||
|
||||
Go 中每个 bucket 最多能存放多少对 key-value？
|
||||
|
||||
A. 16 对
|
||||
B. 8 对
|
||||
C. 取决于 key 和 value 的类型大小
|
||||
D. 没有限制，可以无限增长
|
||||
|
||||
### Q2（基础）→ 行为判断
|
||||
|
||||
以下代码的运行结果是什么？
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
m := make(map[string]int)
|
||||
m["a"] = 1
|
||||
|
||||
for i := 0; i < 5; i++ {
|
||||
delete(m, "b") // 删除一个不存在的 key
|
||||
}
|
||||
|
||||
fmt.Println(len(m))
|
||||
}
|
||||
```
|
||||
|
||||
A. panic — 不能删除不存在的 key
|
||||
B. 0
|
||||
C. 1
|
||||
D. 不确定（随机值）
|
||||
|
||||
### Q3（进阶）→ 核心原理
|
||||
|
||||
Go map 在什么条件下会触发渐进式扩容（GrowLoad）？
|
||||
|
||||
A. 当元素数量超过 `make` 时传入的 hint 值时
|
||||
B. 当负载因子 `count / 2^B >= 6.5` 或 overflow bucket 总数 ≥ 32768 时
|
||||
C. 当执行了第一次写入操作时
|
||||
D. 当调用 `len(m)` 超过 1000 次时
|
||||
|
||||
### Q4（进阶）→ 比较与辨析
|
||||
|
||||
关于 `sync.Map` 和普通 `map + RWMutex` 的选择，以下哪个场景最适合使用 `sync.Map`？
|
||||
|
||||
A. 高频写入、key 集合频繁变化、需要遍历全部数据
|
||||
B. 读远大于写（如缓存只读路径）、key 集合相对稳定、不需要遍历 dirty map
|
||||
C. 只需要简单加锁即可满足并发需求的所有场景
|
||||
D. 任何需要并发安全的 map 都应该默认用 sync.Map
|
||||
|
||||
### Q5（深入）→ 场景推理
|
||||
|
||||
在一个 goroutine 遍历某个 map 的同时，另一个 goroutine 向该 map 中插入新元素，会发生什么？
|
||||
|
||||
A. 正常运行，两个操作互不影响
|
||||
B. 遍历时删除已有 key 是合法的（后续不会再出现），但插入新元素可能导致 panic 或死循环
|
||||
C. 自动加读锁保护，不会 panic
|
||||
D. 只有在新元素被哈希到新创建的 bucket 时才可能出问题
|
||||
|
||||
### Q6（深入）→ 源码级边界场景
|
||||
|
||||
关于 map 遍历顺序的行为，以下描述最准确的是：
|
||||
|
||||
A. Go 1.12 之前遍历是确定性的（按 bucket 索引顺序），之后改为随机以防御依赖特定顺序的代码
|
||||
B. 遍历顺序完全随机，每次运行时无法预测任何顺序
|
||||
C. map 按照插入顺序遍历，保证 FIFO
|
||||
D. 遍历顺序与 key 的哈希值成正比，始终有序
|
||||
|
||||
---
|
||||
|
||||
## 二、填空题（3道）
|
||||
|
||||
### F1 — 桶索引计算
|
||||
|
||||
已知某 map 的 `B = 3`（即 2^3 = 8 个 bucket），对一个 key 计算出的哈希值低 3 位为 `0x78 & 0x7`。请问该 key 会被分配到哪个 bucket 索引？
|
||||
|
||||
计算公式：`index = hash & (2^B - 1)`
|
||||
|
||||
bucket 索引 = _____（十进制表示）
|
||||
|
||||
> **提示**: `2^3 - 1 = 7`，即二进制 `0b111`，等价于取最低 3 位。`0x78` 的最低三位是多少？
|
||||
|
||||
### F2 — 扩容搬迁方向
|
||||
|
||||
map 扩容时将原来的 1 个 bucket 拆分为 2 个新 bucket。假设旧桶索引为 `i = hash & (2^B - 1)`，扩容后 B 变为 `B+1`，同一个 key 可能被分配到新桶 `i` 或新桶 `i + _____`（用含 B 的表达式填写偏移量）。
|
||||
|
||||
> **提示**: 扩容后的桶数组大小翻倍，hash 的高一位（第 B 位）决定了 key 去旧桶还是新桶。偏移量等于旧桶数组的大小，即 `2^B`。
|
||||
|
||||
### F3 — hmap 字段填空
|
||||
|
||||
```go
|
||||
type hmap struct {
|
||||
count int
|
||||
flags uint8
|
||||
B uint8 // 桶的数量对数：实际 bucket 数 = 2^_____
|
||||
nhash uint64
|
||||
nreadings uint64
|
||||
nwrite uint64
|
||||
buckets unsafe.Pointer // 指向当前 bucket 数组
|
||||
oldbuckets unsafe.Pointer // 扩容时的旧 bucket 数组
|
||||
nevacuate uintptr // 迁移进度标记
|
||||
extra *mapextra
|
||||
}
|
||||
```
|
||||
|
||||
`B` 字段控制实际 bucket 数量：`bucket 数量 = 2^_____`
|
||||
|
||||
两处空白都填同一个符号：_____
|
||||
|
||||
> **提示**: B 是一个对数值，实际桶数是 2 的 B 次方。
|
||||
|
||||
---
|
||||
|
||||
## 三、简答题（1道）
|
||||
|
||||
### S1
|
||||
|
||||
你在开发一个高并发的 API 网关，其中有一个 `rateLimit` map 用于记录每个客户端 IP 的请求次数。初期你使用普通 `map[string]int`，在并发压测时遇到了 `concurrent map writes` panic。于是你把方案改成了 `sync.Map`，但性能反而不如加了 `RWMutex` 的版本。
|
||||
|
||||
请结合 Go map 的底层设计，分析：
|
||||
1. 为什么普通 map 并发不安全？（从数据结构层面解释）
|
||||
2. 为什么在这个场景下 `sync.Map` 比 `RWMutex + 普通 map` 更差？
|
||||
3. 如果坚持要用 `sync.Map`，应如何评估它是否适合你的场景？
|
||||
|
||||
> **答题框架提示**:
|
||||
> 1. 从 hmap 和 bucket 的角度解释并发写为何导致 crash
|
||||
> 2. 对比 sync.Map 的内部 read/dirty 双表机制与普通 map 的适用条件
|
||||
> 3. 给出决策矩阵（读写比例、key 集稳定性、遍历需求）
|
||||
|
||||
---
|
||||
|
||||
## 参考答案与解析
|
||||
|
||||
### 选择题答案
|
||||
|
||||
| 题号 | 正确答案 | 解析 |
|
||||
|------|---------|------|
|
||||
| Q1 | B | 每个 bucket 固定最多容纳 8 对 key-value。这个设计让一个 bucket 正好塞进一条 CPU cache line（通常 64 字节），最大化缓存命中率。超过 8 对时通过 overflow bucket 链表扩展。选项 C 具有迷惑性——虽然溢出链的长度取决于类型，但单个 bucket 内部的槽位数始终是 8。 |
|
||||
| Q2 | C | `delete` 一个不存在的 key 是安全的，不会 panic。`len(m)` 返回当前存储的元素个数，因为只插入了 `"a"` 且从未删除它，所以结果为 1。多次 delete 不存在的 key 不会产生副作用。 |
|
||||
| Q3 | B | Go map 扩容（GrowLoad）在两种情况下触发：(1) 负载因子 ≥ 6.5，即 `count / 2^B >= 6.5`，意味着平均每个 bucket 有超过 6.5 个元素；(2) overflow bucket 总数 ≥ 32768 (`2^15`)。扩容是渐进式的，在写入时逐桶搬运。选项 A 错在 hint 只是建议值，超出不会立即触发扩容；选项 D 毫无根据。 |
|
||||
| Q4 | B | `sync.Map` 内部有两张表：read（无锁热读）和 dirty（带锁写）。它针对"读远大于写、key 集稳定"的场景优化。如果 key 频繁增删，dirty 表中的脏条目不会被 expunge（懒清理），导致 read 和 dirty 都不命中。对于写多或需要遍历的场景，普通 map + RWMutex 更高效。 |
|
||||
| Q5 | B | Go 明确禁止在遍历时向 map 插入新元素——遍历时无法感知新加入的 bucket，可能导致死循环或 panic。但删除已有元素是合法的，因为遍历器在删除后不会再回到那个位置。这是 map 遍历时最大的陷阱之一。 |
|
||||
| Q6 | A | Go 1.12 之前 map 遍历按 bucket 数组的顺序进行，这在某些场景下是有用的确定性行为（例如 memcache 的 get multi 请求）。但从 Go 1.12 起，引入随机 offset 来防止开发者依赖特定顺序——在生产中因测试环境与生产环境的 Go 版本差异导致的 bug 不在少数。"完全随机"不准确，因为 offset 一旦选定后同一趟遍历的顺序是确定的。 |
|
||||
|
||||
### 填空题答案
|
||||
|
||||
| 题号 | 答案 | 解析 |
|
||||
|------|------|------|
|
||||
| F1 | `0` | `2^3 - 1 = 7`，即 `0b111`。`0x78 & 7 = 0x78 & 0b111 = 0b1110000 & 0b111 = 0`。实际上 `0x78 = 120 = 16*7 + 8`，`120 % 8 = 0`，所以索引为 0。这里展示了按位与 `%` 的性能优势：`hash & (2^B - 1)` 等价于取模，但快得多。 |
|
||||
| F2 | `2^B` | 扩容后桶数组大小从 `2^B` 变为 `2^(B+1)`。一个 key 的 hash 在旧数组中落在 index `i`，在新数组中可能落在 `i`（hash 的第 B 位为 0）或 `i + 2^B`（hash 的第 B 位为 1）。这就是说旧 bucket 被"分裂"到了两个新 bucket。 |
|
||||
| F3 | `B` | `B` 是对数意义上的桶数指数，实际 bucket 数量 = `2^B`。B=0 时有 1 个 bucket，B=1 时有 2 个，以此类推。创建 map 时传入的 capacity hint 就是用来估算初始 B 值的。 |
|
||||
|
||||
### 简答题参考答案
|
||||
|
||||
S1：**参考答案要点**：
|
||||
|
||||
1. **普通 map 非线程安全的原因在于 hmap 的状态标志**：多个 goroutine 同时写同一个 map 时，可能对 `flags` 标志位、`nhash` 迭代计数、`buckets` 指针等共享状态产生竞态条件。特别是在扩容期间，新旧 bucket 并存，并发写会导致数据结构损坏进而 panic。Go 选择直接 panic 而非静默出错是有意的设计决策。
|
||||
2. **sync.Map 不适用的原因**：`sync.Map` 针对"大量读 + 少量写"优化，其 read 表是无锁的但只有在条目未被标记为 deleted 时才保证命中。如果场景中存在较多写操作（如 rateLimit 不断更新计数器），dirty 表会不断积压，expunge 跟不上，导致性能退化。此时 `RWMutex` 的写开销虽然是独占的，但逻辑更直接且没有 lazy-expunge 的额外开销。
|
||||
3. **决策评估维度**：(a) 读写比例——read >> write 才值得用 sync.Map；(b) key 集稳定性——频繁增删会使 sync.Map 的 dirty 表膨胀；(c) 是否需要遍历——sync.Map 的 dirty map 遍历是不安全的。本题的 rateLimit 场景属于写相对频繁且 key 集动态变化的类型，RWMutex 更合适。
|
||||
|
||||
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。重点考察是否能从底层数据结构出发理解高层 API 的适用边界。
|
||||
|
||||
## 关联笔记
|
||||
- [[00.Go/data-structures/切片底层实现]] — Slice 是 Map bucket 内部的数组类型，理解切片有助于理解 Map 的扩容和数据组织
|
||||
@@ -0,0 +1,199 @@
|
||||
---
|
||||
tags: [test/review, go, slice, append-growth, memory-allocation]
|
||||
create time: 2026-08-09 12:00
|
||||
---
|
||||
|
||||
# 切片底层实现_测试题
|
||||
|
||||
## 概述
|
||||
本测试覆盖 Go 切片的内部结构、nil/empty 区别、append 扩容策略（含 Go 1.18 变化）、三索引切片以及共享底层数组的经典陷阱。共包含 6 道选择题、3 道填空题和 1 道综合简答题。
|
||||
|
||||
---
|
||||
|
||||
## 一、选择题（6道，由浅入深）
|
||||
|
||||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||||
|
||||
### Q1（基础）— 考察定义层面
|
||||
|
||||
在 64 位平台上，`unsafe.Sizeof(s)` 对一个类型为 `[]int` 的切片变量 s 返回多少字节？
|
||||
|
||||
A. 与切片中元素个数相同，每个元素占 8 字节
|
||||
B. 永远是 24
|
||||
C. 是底层数组的总大小（元素个数 × 元素大小）
|
||||
D. 取决于切片的容量 cap
|
||||
|
||||
### Q2（基础）→ 行为判断
|
||||
|
||||
以下代码的输出是什么？
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import "encoding/json"
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
var s1 []int
|
||||
s2 := make([]int, 0)
|
||||
|
||||
b1, _ := json.Marshal(s1)
|
||||
b2, _ := json.Marshal(s2)
|
||||
|
||||
fmt.Println(string(b1), string(b2))
|
||||
}
|
||||
```
|
||||
|
||||
A. `[] []`
|
||||
B. `null null`
|
||||
C. `null []`
|
||||
D. panic
|
||||
|
||||
### Q3（进阶）→ 核心原理
|
||||
|
||||
Go 1.18 之后，当切片当前容量 `oldCap >= 256` 且触发扩容时，新容量的计算公式是什么？
|
||||
|
||||
A. `newCap = oldCap * 2`
|
||||
B. `newCap = oldCap + oldCap / 2`
|
||||
C. `newCap = oldCap + oldCap / 4`
|
||||
D. `newCap = oldCap + 256`
|
||||
|
||||
### Q4（进阶）→ 比较与辨析
|
||||
|
||||
下面三种切片创建方式中，哪一项描述是正确的？
|
||||
|
||||
```go
|
||||
var s1 []int // 方式一
|
||||
s2 := make([]int, 0) // 方式二
|
||||
s3 := []int{} // 方式三
|
||||
```
|
||||
|
||||
A. 方式一的 `s1 == nil` 为 true，方式二和三的 `s2 == nil` 也为 true
|
||||
B. 方式二和方式三创建的切片，它们的 `ptr` 都指向一块已分配的空数组内存
|
||||
C. 方式一的 `cap` 不为 0，而是等于后续第一次 append 时的默认值
|
||||
D. 三者功能完全等价，没有任何语义或行为差异
|
||||
|
||||
### Q5（深入）→ 场景推理
|
||||
|
||||
```go
|
||||
orig := []byte("Hello, World!") // len=13, cap=13
|
||||
short := orig[:5] // short = "Hello", len=5, cap=13
|
||||
|
||||
saved := short[:cap(short)] // saved 长度为 13，共享 orig 的底层数组
|
||||
copy(saved, "Hi") // 将 "Hi" 复制到 saved 的前三个位置
|
||||
```
|
||||
|
||||
执行后 `string(orig)` 的结果是什么？
|
||||
|
||||
A. `"Hello, World!"` — orig 不受影响
|
||||
B. `"Hi, World!"` — orig 前三个字节被覆盖
|
||||
C. `"Hi"` — orig 长度变为 3
|
||||
D. panic — 越界访问
|
||||
|
||||
### Q6（深入）→ 源码级边界场景
|
||||
|
||||
假设有一个空切片 `s := make([]int, 0, 0)`，对其连续调用 `append(s, 1, 2, 3, ..., 100)` 一次性追加 100 个元素。请问最终切片的容量 cap 是多少？
|
||||
|
||||
A. 200（翻倍到 ≥ 100）
|
||||
B. 100（直接使用目标 cap）
|
||||
C. 128（翻倍两次：0→1→2→...→100 过程中的渐进增长）
|
||||
D. 101（100 + 预留一个）
|
||||
|
||||
---
|
||||
|
||||
## 二、填空题（3道）
|
||||
|
||||
### F1 — 扩容数值计算
|
||||
|
||||
```go
|
||||
s := make([]int, 0, 300)
|
||||
// ... 追加若干元素直到触发扩容
|
||||
// newCap = 300 + 300/4 = _____
|
||||
```
|
||||
|
||||
请计算当 `oldCap = 300` 时首次触发的 `newCap` 值：_____
|
||||
|
||||
> **提示**: 使用 Go 1.18 之后的 1.25x 增长率公式，注意整除运算向下取整。
|
||||
|
||||
### F2 — 三索引切片容量
|
||||
|
||||
```go
|
||||
a := make([]byte, 5) // a: [0 0 0 0 0], len=5, cap=5
|
||||
s1 := a[1:4] // s1: _____, len=3, cap=?
|
||||
s2 := s1[0:2] // s2: [0 0], len=2, cap=?
|
||||
```
|
||||
|
||||
`s1` 的容量 cap = _____；`s2` 受 `s1.cap` 限制，`s2.cap` = _____
|
||||
|
||||
> **提示**: 从原始切片 a 切出 a[1:4] 时，max 省略时默认为 a.cap，因此 s1.cap = a.cap - 1。再对 s1 切分时，新切片的 cap 不能超过 s1.cap。
|
||||
|
||||
### F3 — 缓存复用模式
|
||||
|
||||
```go
|
||||
var cache []int
|
||||
// ... 之前已经往 cache 里 append 了不少数据
|
||||
cache = cache[:0] // 重置长度，保留底层数组
|
||||
for _, item := range items {
|
||||
cache = append(cache, process(item))
|
||||
}
|
||||
// 下一次调用 cache[:0] 即可复用已分配的内存，无需额外的 _____
|
||||
```
|
||||
|
||||
这种模式中 `cache[:0]` 的核心优势是不触发额外的内存分配，因为底层数组保持不变。空白处填该操作避免的操作名：_____
|
||||
|
||||
> **提示**: 对比 `make([]T, expectedSize)` 与 `cache[:0]`，后者跳过了 runtime 层面的哪一步？
|
||||
|
||||
---
|
||||
|
||||
## 三、简答题（1道）
|
||||
|
||||
### S1
|
||||
|
||||
你在设计一个 HTTP 请求处理管道，多个 goroutine 并行处理请求并将结果写入同一个 `results` 切片。某次压测发现结果中出现重复数据和脏数据。排查发现：worker goroutine 接收到 request body 的 `[]byte` 缓冲区后直接将其切分传给下游，而没有做 copy。
|
||||
|
||||
请结合切片底层的至少三个关键知识点，分析为什么会出现这个问题，并给出修正方案。
|
||||
|
||||
> **答题框架提示**:
|
||||
> 1. 先说明切片字段机制（ptr/len/cap 如何操控共享内存）
|
||||
> 2. 再说明多个切片共享同一底层数组的后果
|
||||
> 3. 接着说明 goroutine 并发场景下的具体风险
|
||||
> 4. 最后给出防御方案（copy 断开共享、预分配等）
|
||||
|
||||
---
|
||||
|
||||
## 参考答案与解析
|
||||
|
||||
### 选择题答案
|
||||
|
||||
| 题号 | 正确答案 | 解析 |
|
||||
|------|---------|------|
|
||||
| Q1 | B | 切片头在 64 位平台固定为 24 字节（ptr 8 + len 8 + cap 8），与其中元素数量和容量无关。底层数组的实际大小由运行时独立管理，不包含在切片头内。 |
|
||||
| Q2 | C | `var s1 []int` 创建的是 nil slice（ptr=nil），`encoding/json` 将其序列化为 `null`。`make([]int, 0)` 创建的是 empty slice（有分配底层数组），序列化为 `[]`。这是 nil slice 和 empty slice 最常见的外部可见差异。 |
|
||||
| Q3 | C | Go 1.18 起，当需求 cap ≥ 256 时使用 `newCap = oldCap + oldCap/4`（即 1.25x 增长率）。小容量（< 256）仍然翻倍。这样做避免了大容量切片过度分配。例如 cap=300 时，newCap=375。 |
|
||||
| Q4 | B | 方式一 `var s` 的 ptr 为 nil、len=0、cap=0，`s==nil` 为 true。方式二和方式三的 ptr 都指向 runtime 分配的一块空数组（cap≥1），`s==nil` 为 false。方式三比方式二更明确地表达"需要一个非 nil 的空切片"。选项 A 错在方式二三不是 nil；选项 C 错在方式一的 cap=0；选项 D 错在 JSON 序列化等行为确实不同。 |
|
||||
| Q5 | B | `short` 和 `orig` 共享同一底层数组。`saved := short[:cap(short)]` 将 short 扩展到整个容量（13），然后 `copy(saved, "Hi")` 写入了 `orig[0:3]`，覆盖了原来的 "Hel"，结果为 "Hi, World!"。这是一个真实项目中出现过的 bug 模式。 |
|
||||
| Q6 | B | 根据扩容规则的第 3 步："如果旧 cap 太小而目标 cap 太大，直接用目标 cap"。从零容量开始一次性 append 100 个元素，target cap 为 100，runtime 直接取 100 而非经过多次翻倍。这是扩容逻辑的特殊分支保护。 |
|
||||
|
||||
### 填空题答案
|
||||
|
||||
| 题号 | 答案 | 解析 |
|
||||
|------|------|------|
|
||||
| F1 | `375` | Go 1.18 扩容公式：`oldCap >= 256` 时用 `newCap = oldCap + oldCap/4 = 300 + 75 = 375`。注意整除运算 `300/4 = 75` 恰好整除。 |
|
||||
| F2 | `4`, `2` | `a[1:4]` 相当于 `a[1:4:5]`（省略 max 时取原切片 cap），所以 `s1.cap = 5 - 1 = 4`。`s2 := s1[0:2]` 是从 s1 头部切 2 个元素，显式 cap 计算为 `2-0=2`，所以 `s2.cap = 2`。 |
|
||||
| F3 | `malloc`（或"内存分配"） | `cache[:0]` 仅修改 len 字段为 0，不改变 ptr 和 cap，底层数组继续保持可达。下次 append 时可以直接复用已有空间，跳过 runtime 的 malloc 调用和数据拷贝开销。 |
|
||||
|
||||
### 简答题参考答案
|
||||
|
||||
S1：**参考答案要点**：
|
||||
|
||||
1. **切片头部只有 24 字节的指针/长度/容量，真正的数据在共享的底层数组**——多个 worker 传递的切片可能指向同一块内存。worker 之间传递的是切片头而不是数据的副本。
|
||||
2. **多个 worker 切分同一个 request body 的缓冲区后，它们共享底层数组**——任何一个 worker 对切片的修改（尤其是通过大容量扩展后的 append 操作）都会影响其他 worker 看到的原始数据。
|
||||
3. **goroutine 并发环境下，request body 缓冲区可能被上游（HTTP handler 或 net/http）复用覆盖**——即使没有直接的相互覆盖，buffer pool 的标准回收机制也会在请求结束后重用这块内存，导致后续 worker 读到被改写的数据。
|
||||
4. **防御方案**：通过 `copy(dst, src)` 将需要的数据深拷贝到各自独立的底层数组，彻底断开共享关系。对于已知大小的数据，可以先 `make` 预分配再进行 copy。
|
||||
|
||||
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。重点考察是否理解"切片是遥控器而非容器"这一核心理念。
|
||||
|
||||
## 关联笔记
|
||||
- [[00.Go/data-structures/Map 底层实现]] — Slice 是 Map bucket 内部的数组类型，理解切片有助于理解 Map 的扩容和数据组织
|
||||
- [[00.Go/concurrency/Goroutine 调度模型]] — Goroutine 参数传递中使用切片的注意事项
|
||||
- [[00.Go/runtime/三色标记GC原理]] — 切片作为 GC root 参与可达性分析的过程
|
||||
Reference in New Issue
Block a user