vault backup: 2026-08-09 19:06:40
This commit is contained in:
@@ -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