Go中栈上未逃逸的string为何会被GC？附复现代码

核心结论 #

Go的GC并非只回收堆内存，即使变量在栈上未逃逸，只要它不再被后续代码引用，其指向的堆上底层数据仍会被GC标记回收——这就是你遇到问题的根本原因。

细节拆解 #

1. 字符串的内存结构
   Go的string是一个包含Data指针和Len字段的小结构体：

   • 栈上的xxxxxs只是这个结构体本身，确实未逃逸；
   • 但bufio.Reader.ReadString返回的字符串，其底层字节数组是分配在堆上的。

2. 变量存活期的判断
   在unsafeStringToBytes函数中：

   • 当你通过reflect.StringHeader拿到sh.Data后，后续代码没有再直接使用xxxxxs；
   • Go的编译器和GC会做存活分析，判定xxxxxs的生命周期到此结束，即使函数还没返回，它指向的堆上字节数组也会被标记为可回收。
   • 你手动调用runtime.GC()+后台的heapHeapHeap疯狂分配大内存，会让GC更积极地回收闲置内存，直接触发了数据被覆盖的问题。

3. runtime.KeepAlive的作用
   这个函数的本质是给GC一个明确的信号：xxxxxs必须存活到这行代码执行完毕。它强制延长了xxxxxs的生命周期，确保其指向的堆字节数组在返回[]byte前不会被回收，自然就不会出现数据不一致的情况。

关键误区澄清 #

你看到的xxxxxs does not escape是指字符串的结构体本身留在栈上，而非它指向的底层字节数组。GC回收的是堆上的字节数组，而非栈上的结构体——当结构体失去引用价值后，它关联的堆内存就失去了根引用，必然会被GC处理。

内容的提问来源于stack exchange，提问作者IguoChan