Go 子切片持有大数组为什么导致内存不释放

Go 子切片只描述原数组的一段区域，不会把这一段自动搬到独立数组。只要长期存活的子切片仍引用大数组，垃圾回收器就不能把那块数组当成无用对象回收。解决办法是在结果进入缓存、队列或长期对象前，用 make + copy 复制需要保留的内容，并让原数组的所有引用结束。

我会先看“这段数据要保存多久”，再决定是否复制。请求内临时使用窗口可以减少复制；跨请求保存十几个字节，却保留整块读取缓冲区，通常就值得把所有权分开。下面用一个小缓存例子说明，代码和输出均为教学示例，未在本文制作过程中执行。

Go 官方地址：https://go.dev/

切片官方说明：https://go.dev/blog/slices-intro

前置条件：先分清切片长度与存活对象

len 表示切片当前能索引的元素个数，cap 表示从该切片起点继续扩展的容量范围。二者都不是“这个引用使多少堆内存保持存活”的统计值。子切片的数据引用仍可能落在一个很大的底层数组中；垃圾回收不会把该数组按切片长度裁成若干块。

本例把关系分成三个部分：缓存持有中的缓存变量、子切片；切片描述中的数据引用、长度与容量；存储对象中的底层大数组。缓存变量保存子切片，子切片包含数据引用以及长度与容量，数据引用关联底层大数组。即使原来的局部变量离开函数，这条保留关系仍在。

这里讨论普通 Go 切片及堆对象保留，不讨论 unsafe 构造的切片或操作系统映射文件。下面的 24 MiB 是示例数组的数据规模，不是测量所得的进程内存。

初始化：让缓存明确持有一个小窗口

先把问题收敛到一个拥有明确生命周期的变量：包级 cached 保存结果，retainWindow 创建读取缓冲区并选取窗口。初始分支直接把 window 放入缓存，修复分支复制相同的 12 字节。两种写法交付相同内容，区别在于结果是否共享大数组。

package main

import (
    "fmt"
    "runtime"
)

var cached []byte

func retainWindow(detach bool) {
    // 模拟一次较大的读取；只把其中 12 字节交给长期缓存。
    source := make([]byte, 24

source 退出函数不会自动撤销 cached 的引用。把 source 设为 nil 也只能改动这个变量，不能改动已经复制到缓存里的切片描述符。这个例子故意使用包级缓存表达长期持有；真实程序中对应的也可能是 map 条目、结构体字段或闭包捕获。

编写修复：在长期保存前复制所需数据

修复点放在“临时视图成为长期结果”的位置。本例使用 make([]byte, len(window)) 创建结果存储，再用 copy 搬移字节。结果长度与容量都为 12，之后读取它不依赖原缓冲区。复制与原缓冲区复用之间也要有正确的同步关系，不能一边复制一边让其他 goroutine 改写相同字节。

第二张图只表示修复分支的静态关系。临时读取包含 source 与 window；复制边界包含 make、copy；长期保存包含 owned 与 cached。source 与 window 共享存储，make 为 owned 提供独立存储，copy 同时关联源 window 和目标 owned，cached 保存 owned。连线表示这些关系，不表示执行时间顺序。

我倾向于在返回值或入缓存处写清楚所有权约定，而不是在每一次截取时复制。例如约定“解析函数返回独立字节副本”，调用方就能放心长期保存。代价是一次分配和按结果长度复制；是否值得，应结合保存时长、结果大小与请求量判断。

运行检查：比较引用关系与预期现象

把完整示例保存为独立目录里的 main.go 后，可以自行运行。下面命令只运行该示例，不代表本文已经执行或采集了数据。

# 在仅包含该示例 main.go 的目录中运行，观察两种分支的内容。
go run main.go

按代码可推导的文本输出如下；这是预期输出，不是测量日志。

共享窗口：len=12 内容=cache-window
独立副本：len=12 内容=cache-window

输出相同并不能证明没有保留大数组。检查重点应是结果指向哪个存储，以及旧引用是否仍存活：

若自己扩展为内存实验，可用 runtime.ReadMemStats 比较受控条件下的 HeapAlloc，并在采样之后用 runtime.KeepAlive 保持需要观察的切片存活，避免编译器提前结束局部变量的活跃期。两个分支最好在独立进程中比较，减少前一次分配和 GC 时机的干扰。不要把一次输出、单次 RSS 变化当成固定的内存承诺。

runtime.GC() 不能收走仍可达的数组。失去引用、完成垃圾回收以及运行时向操作系统归还物理内存，也不是同一件事。修复引用关系后 RSS 没立刻下降，并不能单独证明修复失败。

扩展实验：容量限制和浅拷贝各管什么

最容易误判的是三下标切片和 slices.Clip。它们可以限制切片容量，却不会把现有元素复制到新的小数组。对于非空窗口，即使看到 cap == len，仍可能持有原来的大对象。下面的小片段用原地改写来解释共享关系，不做堆内存测量。

package main

import (
    "fmt"
    "slices"
)

func main() {
    original := []byte("parcel-data")
    limited := original[0:6:6] // 限制容量，但仍与 original 共享元素。
    clipped := slices.Clip(limited)
    cloned := slices.Clone(limited) // 本例为非空字节切片，复制后可独立改写。

    original[0] = 'P' // 共享视图跟随变化，独立副本保留旧内容。
    fmt.Println(string(clipped), string(cloned))
}

按此代码，预期得到 Parcel parcel。Clip 的容量约束有助于隔离后续 append 对额外容量的使用，不能据此称它“释放多余数组”。Clone 复制元素，容量也未必等于长度；需要明确控制本例结果容量时，前面的 make + copy 更直观。

还要留意元素类型。[]byte 复制的是字节值，而 [][]byte 或含指针字段的结构体切片，浅复制后内部引用仍可能关联旧数据。外层数组独立，不代表整个对象图独立。空结果也不需要继续保存视图：如果接口允许，可以直接返回 nil，避免用空切片的长度推断是否解除存储关联。

清理与相关问题：找到最后一个持有者

真实项目可以沿缓存字段、队列元素和闭包捕获逐项寻找持有者。只删除一个局部变量并不够；复制后还保留原窗口的其他副本，也会继续保留大数组。清理必须发生在业务不再需要数据时，不能为了降低内存而提前清除仍被消费者使用的结果。

把子切片设为 nil，原数组就一定释放吗？

仅当它是最后一条有效保留关系时，原数组才可能进入可回收状态。其他切片、字段或闭包仍引用该对象时，清理当前变量没有这个效果。

把切片缩短成零长度是否等于解除引用？

不等于。缩短窗口不会自动复制或解除底层存储关联。对于不再需要的字段，应按业务语义清除引用；需要保留少量内容时则复制该内容。

应该把所有子切片都复制吗？

不必。同一次处理中的短期视图适合共享；结果长期保存且原缓冲区明显更大时适合复制。这个判断围绕生命周期与所有权展开，比仅比较 len 或 cap 更有效。

官方资料：切片与底层数组关系见 https://go.dev/blog/slices-intro；切片表达式与 copy 规则见 https://go.dev/ref/spec；Clip、Clone 见 https://pkg.go.dev/slices；采样与 KeepAlive 见 https://pkg.go.dev/runtime；GC 和内存归还的区别见 https://go.dev/doc/gc-guide。