Go 泛型切片函数:你可能忽略的内存陷阱

2 阅读5分钟

Go 1.21 引入了 slices 标准库包,提供了一批操作切片的通用工具函数。但如果你不理解切片的底层内存模型,很容易写出看起来正确、实则存在内存泄漏的代码。本文结合 Go 官方博客,带你把这件事彻底讲清楚。


泛型让切片函数写一次就够了

在泛型出现之前,如果你想实现一个"在切片中查找元素"的函数,就得为每种类型各写一份。有了类型参数,只需写一次:

// Index 返回 v 在 s 中第一次出现的下标,若不存在则返回 -1
func Index[S ~[]E, E comparable](s S, v E "S ~[]E, E comparable") int {
    for i := range s {
        if v == s[i] {
            return i
        }
    }
    return -1
}

slices 包正是基于这一思路,提供了 CloneSortCompactDeleteInsertReplace 等大量通用函数,覆盖了日常操作切片的主要场景:

s := []string{"Bat", "Fox", "Owl", "Fox"}
s2 := slices.Clone(s)
slices.Sort(s2)
fmt.Println(s2) // [Bat Fox Fox Owl]
s2 = slices.Compact(s2)
fmt.Println(s2)                  // [Bat Fox Owl]
fmt.Println(slices.Equal(s, s2)) // false

先回顾切片的底层结构

切片在 Go 内部由三个字段构成:指针(指向底层数组)、长度容量。两个切片可以共享同一个底层数组,也可以指向数组的不同区段。

s := make([]T, 4, 6)

底层数组: [ e0 | e1 | e2 | e3 | -- | -- ]
                ↑
              s.ptr
s.len = 4, s.cap = 6

这个结构决定了一件重要的事:如果一个函数需要改变切片的长度,它必须返回新的切片。这也是为什么 appendslices.Compact 有返回值,而 slices.Sort(只是重新排列元素)没有返回值。


Delete 的实现原理

在泛型出现之前,从切片中删除一段元素的惯用写法是:

s = append(s[:2], s[5:]...)

语法繁琐,极易写错。slices.Delete 把这件事封装成了一行:

func Delete[S ~[]E, E any](s S, i, j int "S ~[]E, E any") S {
    return append(s[:i], s[j:]...)
}

其行为是:把 s[j:] 的元素向左移动,覆盖掉 s[i:j],再返回长度缩短后的新切片。底层数组本身没有重新分配,只是发生了元素的移动。


Go 1.22 之前的内存泄漏问题

问题就藏在这里。

假设切片中存储的是指针类型(比如 *Image),在删除操作后,虽然新切片的长度缩短了,但底层数组尾部那些"超出长度"的位置,依然持有着原来的指针

删除前: [ p0 | p1 | p2 | p3 | p4 | p5 | -- | -- ]
调用 Delete(s, 2, 5) 后:
        [ p0 | p1 | p5 | p3 | p4 | p5 | -- | -- ]
                            ↑这里的指针没有被清除
新切片长度为 3,但 p3、p4、p5 仍被底层数组引用

垃圾回收器无法释放 p3p4p5 指向的对象,因为底层数组还"看得见"它们。如果这些指针指向的是几十 MB 的大对象,就会造成显著的内存泄漏。


Go 1.22 的修复:自动清零尾部元素

Go 团队在 Go 1.22 中修改了 CompactCompactFuncDeleteDeleteFuncReplace 这五个函数的实现,在操作完成后,用新增的内置函数 clear(Go 1.21 引入)将尾部多余的位置清零:

修复后,Delete(s, 2, 5) 的内存状态:
[ p0 | p1 | p5 | nil | nil | nil | -- | -- ]
                      ↑ 已清零,GC 可以正常回收

对于指针、切片、map、chan、interface 类型,零值就是 nil,GC 因此可以正常回收这些对象的内存。

这个改动没有修改任何 API,开发者无需更改代码,内存泄漏问题就自动消失了。


使用这些函数的常见错误

Go 1.22 的修复也带来了一个副作用:之前一些"侥幸通过"的错误写法,现在会在测试中暴露出来。以下是几种典型错误:

错误一:忽略返回值

slices.Delete(s, 2, 3) // 错误!返回值被丢弃
// s 的长度没变,但内容已被修改,且尾部被置为 nil

错误二:对 Compact 也忽略返回值

slices.Sort(s)    // 正确
slices.Compact(s) // 错误!同样需要接收返回值

错误三:把返回值赋给另一个变量,但继续使用原切片

u := slices.Delete(s, 2, 3) // 之后还用 s?错误!
// s 的底层数组已被修改,尾部元素变成了 nil

错误四:用 := 而非 = 赋值,导致变量遮蔽

s := slices.Delete(s, 2, 3) // 注意:这里用了 :=
// 在某些作用域下,这会创建新变量,原来的 s 依然在外层作用域中被误用

小结

slices 包是对 Go 切片操作的一次重要升级,泛型让这些函数真正做到了"写一次,处处可用"。

使用时记住两件事:

  1. 凡是会改变切片长度的函数(Delete、Compact、Insert、Replace 等),都必须接收并使用它们的返回值,原切片在调用后应视为无效。

  2. Go 1.22 已经自动处理了尾部元素的内存清零问题,你不再需要手动把多余的指针设为 nil,但前提是你正确地使用了返回值。

如果你的项目还在用 Go 1.21 或更早的版本,并且用到了 slices.Delete 等函数操作包含指针的切片,建议关注这个内存泄漏问题,并考虑升级到 Go 1.22+。


参考资料