303 lines
11 KiB
Markdown
303 lines
11 KiB
Markdown
---
|
||
tags: [go/lang, slice, memory-allocation, append-growth, array]
|
||
create time: 2026-08-08 19:00
|
||
update time: 2026-08-08 19:00
|
||
---
|
||
|
||
# 切片底层实现
|
||
|
||
## 概述
|
||
|
||
切片（Slice）是 Go 语言中最常用的集合抽象，它不是简单的数组别名，而是一段指向连续内存的轻量级描述符。理解切片的底层结构——指针、长度、容量——以及 `append` 扩容时的精确策略，是写出高性能 Go 代码的基础，也是后端面试中经久不衰的核心考点。本文将深入到 runtime 源码级别，讲透切片的每一个行为细节。
|
||
|
||
> [!NOTE] 一个关键认知
|
||
> 切片本身不是一个容器，它是容器的"遥控器"——三个字段操控着一块共享的底层数组。理解了这一点，几乎所有切片相关的坑都迎刃而解。
|
||
|
||
## 核心原理
|
||
|
||
### 切片的内部结构
|
||
|
||
在 Go 的运行时中，切片的底层结构由 `reflect.SliceHeader` 和编译期直接操作的 `slice` struct 共同定义。你可以把切片想象成一个三字段的小对象：
|
||
|
||
```mermaid
|
||
graph TD
|
||
A["slicestruct<br/>ptr / len / cap"] --> B["底层数组 backing array<br/>[ elem0 | elem1 | elem2 | ... ]"]
|
||
|
||
subgraph "切片头部 24 bytes x64"
|
||
A
|
||
end
|
||
|
||
subgraph "堆或栈上的连续内存"
|
||
B
|
||
end
|
||
|
||
A -.->|"ptr: 首元素地址"| C["elem0"]
|
||
style A fill:#e3f2fd,stroke:#1565c0,color:#000
|
||
style B fill:#fff3e0,stroke:#e65100,color:#000
|
||
```
|
||
|
||
三个字段各有其责：
|
||
|
||
| 字段 | 大小 (x64) | 含义 | 可达性分析 |
|
||
|------|-----------|------|----------|
|
||
| `ptr` | 8 bytes | 指向底层数组的第一个元素 | GC 根节点 |
|
||
| `len` | 8 bytes | 当前可访问的元素个数 | 普通整数 |
|
||
| `cap` | 8 bytes | 底层数组的总容量 | 普通整数 |
|
||
|
||
切片只有 `len` 个元素对调用者可见，`cap` 之外的内存虽然存在但不可通过索引访问。这种设计让切片可以高效地表示子数组视图。
|
||
|
||
> [!TIP] 面试常考点
|
||
> `unsafe.Sizeof(VarSlice)` 在 64 位平台上永远是 24，无论切片里存了多少元素。切片头很小，真正的数据在别处。
|
||
|
||
### make() vs 切片字面量 vs nil
|
||
|
||
创建切片有三种方式，它们在零值和语义上有本质区别：
|
||
|
||
```go
|
||
var s1 []int // nil slice，ptr=nil, len=0, cap=0
|
||
s2 := make([]int, 0) // empty slice，ptr=new(array), len=0, cap=1
|
||
s3 := []int{} // empty slice，与 s2 等价
|
||
```
|
||
|
||
三种状态的区别：
|
||
|
||
| 创建方式 | ptr | len | cap | `s == nil` | 适用场景 |
|
||
|---------|-----|-----|-----|-----------|---------|
|
||
| `var s []int` | nil | 0 | 0 | true | 延迟初始化、可选参数默认值 |
|
||
| `make([]int, 0)` | new(array) | 0 | 1 | false | 需要立即 append 的场景 |
|
||
| `[]int{}` | new(array) | 0 | 1 | false | 明确表达"我需要一个空切片" |
|
||
|
||
为什么区分 nil slice 和 empty slice？因为 JSON 序列化行为不同：`encoding/json` 将 nil slice 编码为 `null`，empty slice 编码为 `[]`。这在 API 设计中很重要。
|
||
|
||
**nil slice 的优势**：`append` 到 nil slice 上会安全地分配一个新数组，这是 Go 的标准用法。
|
||
|
||
```go
|
||
var result []string
|
||
result = append(result, "hello") // 完全合法，自动分配
|
||
_ = result // ["hello"], cap=1
|
||
```
|
||
|
||
### append 扩容策略详解
|
||
|
||
`append` 是切片最核心的操作，它的行为取决于剩余容量是否充足：
|
||
|
||
```
|
||
若 len(s) < cap(s):
|
||
→ 直接在底层数组的[len]位置写入新元素
|
||
→ len++，返回同一底层数组的切片
|
||
→ ptr/底层数组不变，仅更新 len
|
||
|
||
若 len(s) == cap(s):
|
||
→ 必须分配更大的底层数组
|
||
→ 旧数组内容全部拷贝到新数组
|
||
→ 写入新元素，返回新的切片头
|
||
→ ptr 改变，len 和 cap 都改变
|
||
```
|
||
|
||
扩容时新容量的计算是面试官最喜欢深挖的部分。Go 1.18 之后使用以下公式（简化自 `runtime/growalloc.go`）：
|
||
|
||
```
|
||
当新需求 cap < 256 时：newCap = oldCap * 2
|
||
当新需求 cap >= 256 时：newCap = oldCap + oldCap/4
|
||
|
||
即 growth ratio = 1.25（每次增长约 25%）
|
||
```
|
||
|
||
但这个公式有一个重要的修正机制。实际代码中的逻辑分四步走：
|
||
|
||
1. 先按上述公式算出 `newCap`
|
||
2. 如果 `newCap` 小于目标 `cap`（边界情况），则将 `newCap` 翻倍直到满足要求
|
||
3. 如果旧 `cap` 太小而目标 `cap` 太大（例如从 0 追加 1000 个元素），直接用目标 `cap`
|
||
4. 最终用 `math.MaxInt` 做兜底保护，防止整数溢出
|
||
|
||
这个设计非常实用：小切片翻倍可以尽快达到可用规模，大切片 25% 的增长率则避免了过度分配造成的内存浪费。一个容量 10000 的切片扩容时只多分配 2500，而不是翻倍到 20000。
|
||
|
||
> [!WARNING] 常见误区
|
||
> 很多人以为所有情况都是翻倍扩容，这是基于早期 Go 版本的印象。实际上从 Go 1.18 起，≥256 的阈值就是 1.25x 增长率。
|
||
|
||
### append 扩容演示
|
||
|
||
```go
|
||
func main() {
|
||
s := make([]int, 0, 2) // cap=2
|
||
fmt.Println(cap(s)) // 2
|
||
|
||
s = append(s, 1, 2) // len=2, cap=2，刚好满
|
||
s = append(s, 3) // 触发扩容：2*2=4, newCap=4
|
||
fmt.Println(cap(s)) // 4
|
||
|
||
s = append(s, 4, 5, 6) // 触发扩容：4+4/4=5, newCap=5
|
||
fmt.Println(cap(s)) // 8（实际取min(maxCap,cap*2)的上限处理）
|
||
|
||
s = append(s, 7) // 再次触发扩容
|
||
fmt.Println(cap(s)) // 16
|
||
|
||
s = append(s, 8) // cap=16>=256不成立，继续翻倍
|
||
fmt.Println(cap(s)) // 32
|
||
|
||
// 当 cap 达到 256 后切换为 1.25x 增长
|
||
s = make([]int, 0, 300)
|
||
for i := 0; i < 10; i++ {
|
||
s = append(s, 0)
|
||
if i > 0 && i%3 == 0 {
|
||
fmt.Printf("cap: %d\n", cap(s))
|
||
}
|
||
}
|
||
}
|
||
// cap: 375 (300 + 300/4)
|
||
// cap: 468 (375 + 375/4)
|
||
// cap: 585 (468 + 468/4)
|
||
```
|
||
|
||
### 数组到切片的隐式转换
|
||
|
||
Go 允许通过切片表达式将完整数组转为切片：
|
||
|
||
```go
|
||
arr := [5]int{1, 2, 3, 4, 5}
|
||
s := arr[:] // 等价于 arr[0:5]
|
||
|
||
fmt.Printf("type: %T\n", s) // type: []int
|
||
|
||
// 底层关系：s.ptr == &arr[0]，len=5，cap=5
|
||
```
|
||
|
||
关键点：**数组到切片的转换只是构造了一个切片头，底层数组本身不参与 GC 引用计数调整**。数组如果是栈上的局部变量，编译器逃逸分析决定它是否被分配到堆上。
|
||
|
||
切片表达式还有更强大的形式 `[low : high : max]`（三索引切片）：
|
||
|
||
```go
|
||
a := make([]byte, 5) // [0 0 0 0 0], len=5, cap=5
|
||
s1 := a[1:4] // [0 0 0], len=3, cap=4 (cap = 5-1)
|
||
s2 := s1[0:2] // [0 0], len=2, cap=2 (受 s1.cap 限制)
|
||
|
||
// 三索引写法的显式写法：
|
||
s3 := a[1:4:5] // [0 0 0], len=3, cap=4
|
||
s4 := a[1:4:5][:3] // 这会 panic！s4.cap=4 但试图访问索引3
|
||
```
|
||
|
||
三索引切片的 `max` 参数限制了切片的最大容量，防止后续操作越界到原始数组的后半段。
|
||
|
||
> [!TIP] 面试加分项
|
||
> 指出三索引切片是 Golang 1.20 之前的主要做法，后来官方推荐用显式的 `s[:newLen:newCap]` 替代，语法更一致。
|
||
|
||
## 代码示例
|
||
|
||
### append 共享底层数组的经典陷阱
|
||
|
||
```go
|
||
func SplitAndSum(input []int) ([][]int, int) {
|
||
halves := [][]int{
|
||
input[:len(input)/2], // 前半段
|
||
input[len(input)/2:], // 后半段
|
||
}
|
||
sum := 0
|
||
for _, h := range halves {
|
||
for _, v := range h {
|
||
sum += v // 累加求和
|
||
}
|
||
}
|
||
return halves, sum
|
||
}
|
||
|
||
func main() {
|
||
nums := []int{1, 2, 3, 4, 5, 6}
|
||
parts, total := SplitAndSum(nums)
|
||
parts[0][0] = 99 // ⚠️ 修改前半段会影响 original nums!
|
||
// 因为 halves 和 nums 共享同一个底层数组
|
||
_ = total
|
||
}
|
||
```
|
||
|
||
这段代码暴露了切片的一个本质特性：**多个切片可以同时引用同一块底层内存**。当你需要"分割"数据但不希望后续修改互相影响时，必须先 `copy`：
|
||
|
||
```go
|
||
first := make([]int, len(input)/2)
|
||
copy(first, input[:len(input)/2]) // 深拷贝，断开共享
|
||
second := input[len(input)/2:]
|
||
_ = first
|
||
_ = second
|
||
```
|
||
|
||
### 预分配 vs 动态扩容的性能差异
|
||
|
||
```go
|
||
func appendWithoutPrealloc(n int) []int {
|
||
var result []int // 从 nil 开始，逐步扩容
|
||
for i := 0; i < n; i++ {
|
||
result = append(result, i)
|
||
}
|
||
return result
|
||
}
|
||
|
||
func appendWithPrealloc(n int) []int {
|
||
result := make([]int, n) // 一次性分配
|
||
for i := 0; i < n; i++ {
|
||
result[i] = i
|
||
}
|
||
return result
|
||
}
|
||
|
||
// 性能差距显著：对于百万级切片，
|
||
// 预分配版本减少了多次 malloc/copy 的开销
|
||
// 且避免了中间态垃圾对象的产生
|
||
```
|
||
|
||
预分配的核心优势有两点：一次分配零拷贝 vs 多次分配带拷贝。如果大致知道最终大小，`make([]T, 0, expectedSize)` 是最佳实践。
|
||
|
||
### 切片重切的副作用演示
|
||
|
||
```go
|
||
func DemonstrateSharing() {
|
||
orig := []byte("Hello, World!") // cap=13
|
||
short := orig[:5] // "Hello", 共享底层数组
|
||
|
||
// 如果给 short 预留空间并 append，会覆盖 orig 的内容
|
||
saved := short[:cap(short)] // 扩展回 full length
|
||
copy(saved, "Hi") // orig[0:3] 也被改成 "Hi"
|
||
|
||
println(string(orig)) // "Hi, World!" —— 被意外修改了！
|
||
}
|
||
```
|
||
|
||
这是一个在 real world 项目中真实出现过的 bug。防御方式是避免将短切片以大容量形式暴露给外部代码。
|
||
|
||
## 实践场景
|
||
|
||
### 面试高频问题清单
|
||
|
||
**Q1: `var s []int` 和 `s := []int{}` 有什么区别？**
|
||
两者功能完全等价，区别在于语义表达。`var s` 暗示"延迟初始化"，`[]int{}` 暗示"我现在就要一个空切片"。JSON 序列化时前者输出 `null` 后者输出 `[]`。
|
||
|
||
**Q2: append 会不会修改原切片？**
|
||
这要看原切片是否已满。如果 `len < cap`，append 直接在原底层数组上操作，原切片会自动看到新增元素（因为 len 会变）。如果触发了扩容，则原切片不受影响，因为底层数组已经换了。
|
||
|
||
**Q3: 如何判断两个切片是否共享底层数组？**
|
||
没有内置方法，只能通过逻辑推理。经验法则：任何通过切片表达式产生的新切片，只要范围与原切片有重叠，就必然共享。
|
||
|
||
**Q4: 切片的零值是 nil 吗？nil 切片能用吗？**
|
||
是的。nil 切片可以使用 `append`、`len()`、`range` 等操作，但不能 `copy(dst, nilSlice)`——目标必须非 nil 且有足够容量。
|
||
|
||
### 实战建议
|
||
|
||
- **函数返回值用 pre-allocated 而非 nil**：如果你知道会往返回值 append 数据，用 `make([]T, 0, hint)` 比 `var ret []T` 更高效。
|
||
- **不要把切片内部缓冲区暴露出去**：HTTP handler 接收 request body 后，应该 `copy` 一份所需数据再传给 goroutine，否则原始缓冲区可能被复用覆盖。
|
||
- **`bytes.Buffer` vs `[]byte`**：需要反复追加字节的数据结构时，`bytes.Buffer` 内部用了 `[]byte` 并管理了自己的扩容策略，通常比手动 append 更安全。
|
||
- **`s = s[:0]` 重置技巧**：比重新 `make` 更快，因为底层数组保持不变，下次 append 不会触发额外分配。适合缓存复用的场景。
|
||
|
||
```go
|
||
// 高性能的缓存模式
|
||
var cache []int
|
||
cache = cache[:0] // 重置长度，保留底层数组
|
||
for _, item := range items {
|
||
cache = append(cache, process(item))
|
||
}
|
||
// 下一次调用 cache[:0] 即可复用已分配的内存
|
||
```
|
||
|
||
## 关联笔记
|
||
|
||
- [[Map 底层实现]] — Slice 是 Map bucket 内部的数组类型，理解切片有助于理解 Map 的扩容和数据组织
|
||
- 00.Go/concurrency/Goroutine 调度模型 — Goroutine 参数传递中使用切片的注意事项
|
||
- 00.Go/runtime/三色标记GC原理 — 切片作为 GC root 参与可达性分析的过程
|