Go语言中变量在栈和堆上分配情况分析
一、栈和堆的介绍
栈和堆的基本概念：
- 栈（Stack）：用于存储局部变量和函数调用信息等生命周期与函数调用周期一致的数据。栈上的内存管理是自动进行的，随着函数的进入和退出，相应的内存会被分配和释放。
- 堆（Heap）：用于动态内存分配，适合那些需要在整个程序执行期间保持存在的数据。堆上的内存分配和释放比栈复杂，由垃圾回收器（Garbage Collector, GC）负责管理。
栈（Stack）的特点
- 大小：栈的大小不是固定的，它可以根据需要动态调整，但默认情况下有一个相对较小的初始值。对于Go程序，默认的栈大小是相对保守的，但会根据需求自动增长。具体数值可能随Go版本更新而有所变化，但在较新的版本中，栈开始时非常小（例如几KB），并随着函数调用深度和局部变量的数量增加而自动扩展。
- 单个变量大小：虽然理论上栈可以扩展，但是将大块的数据（如非常大的数组或结构体）直接作为局部变量放在栈上并不是一个好主意。这是因为：
- 栈空间的增长是有成本的，频繁地调整栈大小会影响性能。
- 如果栈上的数据过大，可能会导致栈溢出（stack overflow）错误。
- 在实践中，如果一个变量太大（通常认为超过几KB就比较大了），编译器可能会决定让这个变量“逃逸”到堆上，即使你没有显式地请求这样做。这通过逃逸分析实现。
堆（Heap）的特点
- 大小：堆的大小远大于栈，实际上受限于系统的虚拟内存大小。这意味着你可以分配比栈更大的对象到堆上。然而，堆上的内存分配和释放相比栈来说更加昂贵，因为它涉及到垃圾回收机制，并且需要维护额外的元数据来追踪分配的内存块。
- 单个变量大小：理论上，只要系统有足够的可用内存，你就可以在堆上分配非常大的对象。然而，在实际应用中，分配特别大的对象可能会引发性能问题或内存碎片化问题，尤其是在频繁创建和销毁大对象的情况下。
实际场景考虑
- 栈与堆的选择：一般来说，如果你知道某个变量生命周期较短，并且它的大小适中（通常是几KB以内），那么将其放在栈上是比较合适的。相反，如果变量较大或者其生命周期较长，则应考虑在堆上分配。
- 优化建议：尽量避免在栈上分配过大的局部变量，以防止不必要的栈增长或栈溢出。同时，也要注意过度依赖堆分配可能导致的内存碎片和垃圾回收压力。
总结：在Go语言中，虽然不能像在C或C++中那样通过显式的语法（如malloc或new操作符）直接控制变量是分配在栈上还是堆上，但在某些情况下，编译器的逃逸分析，可以编写代码让编译器将变量分配到堆上。
二、编译器的逃逸分析
为了让编译器能否将变量“逃逸”到堆上，有下面几种方法：
- 返回局部变量的地址：如果你从一个函数返回一个局部变量的地址，那么这个局部变量将会被分配在堆上，因为如果它留在栈上，在函数返回后该地址指向的数据将不再有效。
- 使用new(T)为类型T分配内存时，或者使用复合字面量如&T{}时，这些通常会导致对象在堆上分配。
- 闭包捕获变量：当闭包引用了其外部作用域中的变量，并且这些变量需要在闭包的作用域之外存在时，它们可能会被分配到堆上
代码实例分析
package main
import "fmt"
func createInt() *int {
x := 42 // 这个变量x会被分配到堆上
return &x
}
func makeCounter() func() int {
count := 0 // 可能会逃逸到堆上，特别是如果闭包被返回并长期使用
return func() int {
count++
return count
}
}
func main() {
createInt()
p := new(int) // 分配在堆上
q := &struct{ a, b int }{1, 2} // 同样，这也会导致结构体在堆上分配
fmt.Printf("%p\n", p)
fmt.Printf("%p\n", q)
makeCounter()
}
使用 Go 编译器的 -gcflags="-m" 参数来查看逃逸分析的结果
go build -gcflags="-m" yourfile.go上面代码通过逃逸分析输出如下：
D:\project\go_project\demo\stackHeap>go build -gcflags="-m" main.go
# command-line-arguments
./main.go:5:6: can inline createInt
./main.go:10:6: can inline makeCounter
./main.go:12:9: can inline makeCounter.func1
./main.go:20:11: inlining call to createInt
./main.go:24:12: inlining call to fmt.Printf
./main.go:25:12: inlining call to fmt.Printf
./main.go:27:13: inlining call to makeCounter
./main.go:6:2: moved to heap: x
./main.go:11:2: moved to heap: count
./main.go:12:9: func literal escapes to heap
./main.go:22:10: new(int) escapes to heap
./main.go:23:7: &struct { a int; b int }{...} escapes to heap
./main.go:24:12: ... argument does not escape
./main.go:25:12: ... argument does not escape
./main.go:27:13: func literal does not escape
根据逃逸分析输出信息，以下是明确提到分配到堆上的变量和情况：
- x 变量：
- 来源：./main.go:6:2: moved to heap: x
- 这表明在 createInt 函数中的局部变量 x 被移动到了堆上。这通常是因为函数返回了 x 的地址。
- count 变量：
- 来源：./main.go:11:2: moved to heap: count
- 在 makeCounter 函数中的局部变量 count 也被移动到了堆上。这是因为闭包捕获了这个变量，并且该闭包可能在其定义的作用域之外被调用。
- 匿名函数（func literal）：
- 来源：./main.go:12:9: func literal escapes to heap
- 这意味着在 makeCounter 中定义的匿名函数（闭包）逃逸到了堆上。由于闭包捕获了 count 变量，因此闭包本身也需要在堆上分配以确保其生命周期可以超出定义它的函数作用域。
- 通过 new(int) 分配的对象：
- 来源：./main.go:22:10: new(int) escapes to heap
- 使用 new(int) 创建的整数指针对象分配在堆上。new(T) 总是导致分配在堆上。
- 结构体字面量的地址：
- 来源：./main.go:23:7: &struct { a int; b int }{...} escapes to heap
- 获取结构体字面量的地址并将其作为指针使用时，该结构体实例被分配在堆上。
总结：
- x 和 count 局部变量因为它们的地址被返回或被捕获而分别从栈“逃逸”到堆。
- 匿名函数（闭包） 因为捕获了局部变量而逃逸到堆上。
- 使用 new(int) 创建的对象总是分配在堆上。
- 获取 结构体字面量的地址 导致该结构体实例被分配在堆上。