Golang 切片扩容策略

切片扩容策略

1. 扩容的触发时机

当 append 向切片追加元素时，运行时会检查 Len + appended > Cap。如果超出容量，就必须扩容------分配更大的底层数组，把旧数据拷贝过去，然后把切片的 Data 指针指向新数组。

扩容是一个昂贵的操作：涉及内存分配 + 数据拷贝，时间复杂度 O(n)。所以 Go 的扩容策略在"减少扩容次数"和"避免浪费内存"之间做了精心的平衡。

2. 扩容策略演进

Go 1.17 及之前：经典策略

如果 Cap < 1024 → 新 Cap = 旧 Cap × 2（翻倍）
如果 Cap >= 1024 → 新 Cap = 旧 Cap × 1.25（增长 1/4）

翻倍策略保证了均摊 O(1) 的 append 性能（每次扩容分摊到之前的 n 次 append 上），但当切片很大时翻倍会浪费大量内存，所以 1024 之后改成只增长 1/4。

Go 1.18+：新策略（更平滑的增长曲线）

Go 1.18 对扩容算法做了重新设计（CL 356509），不再有 1024 的硬阈值，而是用一个平滑函数：

新 Cap = 旧 Cap + floor(旧 Cap / 2)  ... 直到某个阈值
更精确的公式（源码 growslice）：
  newcap = old.cap + (old.cap + 3*threshold) / 4
  其中 threshold 在小切片时为 256，随着 Cap 增大逐渐增大

新策略的核心变化：

• 小切片：接近 2 倍增长（如 Cap=1→2, Cap=2→4, Cap=4→8）
• 中等切片：约 1.5~1.75 倍，平滑过渡
• 大切片：趋近 1.25 倍增长

3. 内存对齐：Cap 不是你想的那么简单

扩容算法算出的 newcap 只是一个目标值 ，实际分配的容量还要经过内存分配器的向上取整对齐：

1. 算出需要的字节数：capbytes = newcap * elementsize
2. 按内存分配器的大小类别（size class）向上取整
3. 取整后的字节数 / elementsize = 最终 Cap

Go 的内存分配器（基于 TCMalloc 思想）有一组预定义的大小类别，如 8, 16, 24, 32, 48, 64, 80, 96, 112, 128, ... 字节。当请求 36 字节时，实际分配 48 字节。

这就导致了一个有趣现象：不同元素类型的切片，即使扩容算法算出的目标 Cap 相同，最终的实际 Cap 可能不同。

例如 []int（元素 8 字节）：

• 目标 Cap=5 → 40 字节 → 向上对齐到 48 字节 → 实际 Cap=6
• 目标 Cap=6 → 48 字节 → 实际 Cap=6

4. 扩容后 Data 指针变化

扩容会分配新的底层数组，Data 指针改变：

扩容前：
s.Data ──→ [旧数组]

扩容后：
s.Data ──→ [新数组（更大）]
              ↑ 旧数据已拷贝到这里

这意味着：扩容后，原切片和新切片不再共享底层数组。这就是为什么 append 可能"悄悄"断开共享关系。

5. 扩容策略验证

下面的代码通过不断 append 并记录每次扩容后的 Cap 变化，直观展示 Go 的扩容曲线。

package main

import "fmt"

func main() {
    // 追踪 int 切片扩容曲线
    s := make([]int, 0)
    prevCap := 0
    for i := 0; i < 200; i++ {
        s = append(s, i)
        if cap(s) != prevCap {
            if prevCap == 0 {
                fmt.Printf("Len=%3d  Cap=%3d\n", len(s), cap(s))
            } else {
                ratio := float64(cap(s)) / float64(prevCap)
                fmt.Printf("Len=%3d  Cap=%3d  增长比=%.2f\n", len(s), cap(s), ratio)
            }
            prevCap = cap(s)
        }
    }
}

实际运行输出（Go 1.22, 64 位）：

=== []int 扩容曲线 (元素 8 字节) ===
Len=  1  Cap=  4
Len=  5  Cap=  8  增长比=2.00
Len=  9  Cap= 16  增长比=2.00
Len= 17  Cap= 32  增长比=2.00
Len= 33  Cap= 64  增长比=2.00
Len= 65  Cap=128  增长比=2.00
Len=129  Cap=256  增长比=2.00

可以看到在较小切片阶段，Go 1.18+ 依然保持接近 2 倍的增长。但值得注意的是，第一个 append 时 Cap 直接变成 4（而非 2），这是因为内存分配器最小分配单元的对齐效应。

对于 []byte（元素 1 字节），第一个 append 时 Cap 直接变成 32，因为内存分配器最小分配 32 字节。

6. 扩容断开共享关系

base := make([]int, 3, 3)  // [100, 200, 300]
view := base[:]             // view 共享 base

view = append(view, 400)   // 触发扩容！
// 此时 base = [100, 200, 300]（不变）
// view = [100, 200, 300, 400]（新底层数组）

view[0] = 999               // 不再影响 base
// base[0] 仍然是 100

扩容前，view 和 base 指向同一块内存。扩容后，view 的 Data 指针指向新分配的大数组，与 base 彻底断开。这是 Go 切片最隐蔽的陷阱之一：你以为 append 只是追加，但它可能默默改变了底层引用。

7. 预分配优化

当你知道最终需要多少元素时，用 make([]T, 0, n) 预分配容量可以避免多次扩容和拷贝：

// 不预分配：经历 ~17 次扩容（每次都分配+拷贝）
dynamic := make([]int, 0)
for i := 0; i < 100000; i++ {
    dynamic = append(dynamic, i)
}
// 最终 Cap=110592（远超 100000，因为最后一次扩容翻倍了）

// 预分配：零次扩容
prealloc := make([]int, 0, 100000)
for i := 0; i < 100000; i++ {
    prealloc = append(prealloc, i)
}
// 最终 Cap=100000（精确）

预分配不仅避免了分配开销，还减少了 GC 压力（每次扩容的旧数组都变成垃圾）。

8. 知识要点总结

1. 扩容触发 ：Len + appendCount > Cap 时触发，分配新数组 + 拷贝旧数据。
2. Go 1.18+ 新策略：小切片接近 2 倍，大切片趋近 1.25 倍，中间平滑过渡，不再有 1024 硬阈值。
3. 内存对齐：算出的目标 Cap 会被内存分配器向上取整，导致实际 Cap 可能大于预期。不同元素类型的切片 Cap 不同。
4. 扩容断开共享：append 触发扩容后，Data 指针改变，原切片不受影响。
5. 预分配优化 ：已知最终大小时用 make([]T, 0, n) 预分配，避免多次扩容 + GC 压力。

---