申请到栈内存好处：函数返回直接释放，不会引起垃圾回收，对性能没有影响。
申请到堆上面的内存才会引起垃圾回收。
func F() {
a := make([]int, 0, 20)
b := make([]int, 0, 20000)
l := 20
c := make([]int, 0, l)
}a和b代码一样，就是申请的空间不一样大，但是它们两个的命运是截然相反的。a前面已经介绍过，会申请到栈上面，而b，由于申请的内存较大，编译器会把这种申请内存较大的变量转移到堆上面。即使是临时变量，申请过大也会在堆上面申请。
而c，对我们而言其含义和a是一致的，但是编译器对于这种不定长度的申请方式，也会在堆上面申请，即使申请的长度很短。
堆(Heap)和栈(Stack)
参考 此文 <内存模型：Heap>, <内存模型：Stack>部分的内容:
Heap:
堆的一个重要特点就是不会自动消失，必须手动释放，或者由垃圾回收机制来回收。
Stack:
栈是由于函数运行而临时占用的内存区域
执行main函数时，会为它在内存里面建立一个帧（frame），所有main的内部变量（比如a和b）都保存在这个帧里面。main函数执行结束后，该帧就会被回收，释放所有的内部变量，不再占用空间。
一般来说，调用栈有多少层，就有多少帧。
所有的帧都存放在 Stack，由于帧是一层层叠加的，所以 Stack 被翻译为栈。 (栈这个字的原始含义,就有栅栏的意思,所谓 栈道,栈桥,都是指比较简陋的用栅栏做的道路/桥梁)
即 在函数中申请一个新的对象：
如果分配 在栈中，则函数执行结束可自动将内存回收；不会引起垃圾回收，对性能没有影响。
如果分配在堆中，则函数执行结束可交给GC（垃圾回收）处理;如果这个过程（特指垃圾回收不断被触发）过于高频就会导致 gc 压力过大，程序性能出问题。
C/C++中的new都是分配到堆上,Go则不一定(Java亦然)")
何为逃逸分析(Escape analysis)
在堆上分配的内存,需要GC去回收,而在栈上分配,函数执行完就销毁,不存在垃圾回收的问题. 所以应尽可能将内存分配在栈上.
但问题是,对于一个函数或变量,并不能知道还有没有其他地方在引用. 所谓的逃逸分析,就是为了确定这个事儿~
Go编译器会跨越函数和包的边界进行全局的逃逸分析。它会检查是否需要在堆上为一个变量分配内存，还是说可以在栈本身的内存里对其进行管理。
何时发生逃逸分析?
Go编译器决定变量应该分配到什么地方时会进行逃逸分析
From a correctness standpoint, you don’t need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.
The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function’s stack frame.
However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.
In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.
Q：如何得知变量是分配在栈（stack）上还是堆（heap）上？
A: 准确地说，你并不需要知道。Golang 中的变量只要被引用就一直会存活，存储在堆上还是栈上由内部实现决定而和具体的语法没有关系。
但知道变量的存储位置确实对程序的效率有帮助。如果可能，Golang 编译器会将函数的局部变量分配到函数栈帧（stack frame）上。然而，如果编译器不能确保变量在函数 return 之后不再被引用，编译器就会将变量分配到堆上。而且，如果一个局部变量非常大，那么它也应该被分配到堆上而不是栈上。 当前情况下，如果一个变量被取地址，那么它就有可能被分配到堆上。然而，还要对这些变量做逃逸分析，如果函数 return 之后，变量不再被引用，则将其分配到栈上。
可以使用go命令的 -gcflags="-m"选项，来观察逃逸分析的结果以及GC工具链的内联决策 ([内联是一种手动或编译器优化，用于将简短函数的调用替换为函数体本身。这么做的原因是它可以消除函数调用本身的开销，也使得编译器能更高效地执行其他的优化策略。我们可以显式地在函数定义前面加一行//go:noinline 注释让编译器不对函数进行内联)
实例
对于escape1.go代码如下:
package main
import "fmt"
func main() {
fmt.Println("Called stackAnalysis", stackAnalysis())
}
//go:noinline
func stackAnalysis() int {
data := 100
return data
}通过 go build -gcflags "-m -l" escape1.go go build -gcflags=-m escape1.go 来查看和分析逃逸分析:
./escape1.go:6:13: inlining call to fmt.Println
./escape1.go:6:14: "Called stackAnalysis" escapes to heap
./escape1.go:6:51: stackAnalysis() escapes to heap
./escape1.go:6:13: []interface {}{...} does not escape
:1: .this does not escape escapes to heap 即代表该行该处 内存分配发生了逃逸现象. 变量需要在函数栈之间共享(这个例子就是在main和fmt.Println之间在栈上共享)
- 第6行第13个字符处的字符串标量"Called stackAnalysis"逃逸到堆上
- 第6行51个字符处的函数调用stackAnalysis()逃逸到了堆上
对于escape2.go代码如下:
package main
import "fmt"
func main() {
fmt.Println("Called heapAnalysis", heapAnalysis())
}
//go:noinline
func heapAnalysis() *int {
data := 100
return &data
}执行go build -gcflags=-m escape2.go:
# command-line-arguments
./escape2.go:6:13: inlining call to fmt.Println
./escape2.go:11:2: moved to heap: data
./escape2.go:6:14: "Called heapAnalysis" escapes to heap
./escape2.go:6:13: []interface {}{...} does not escape
:1: .this does not escape
函数heapAnalysis返回 int类型的指针,在main函数中会使用该指针变量. 因为是在heapAnalysis函数外部访问,所以data变量必须被移动到堆上
主函数main会从堆中访问该data变量
(可见指针虽能够减少变量在函数间传递时的数据值拷贝,但不该所有类型数据都返回其指针.如果分配到堆上的共享变量太多会增加了GC的压力)
逃逸类型
1. 指针逃逸:
对于 escape_a.go:
package main
type Student struct {
Name string
Age int
}
func StudentRegister(name string, age int) *Student {
s := new(Student) //局部变量s逃逸到堆
s.Name = name
s.Age = age
return s
}
func main() {
StudentRegister("dashen", 18)
}执行 go build -gcflags=-m escape_a.go
# command-line-arguments
./escape_a.go:8:6: can inline StudentRegister
./escape_a.go:17:6: can inline main
./escape_a.go:18:17: inlining call to StudentRegister
./escape_a.go:8:22: leaking param: name
./escape_a.go:9:10: new(Student) escapes to heap
./escape_a.go:18:17: new(Student) does not escapes 虽然为 函数StudentRegister()内的局部变量, 其值通过函数返回值返回. 但s 本身为指针类型. 所以其指向的内存地址不会是栈而是堆.
这是一种典型的变量逃逸案例
2. 栈空间不足而导致的逃逸(空间开辟过大):
对于 escape_b.go:
package main
func InitSlice() {
s := make([]int, 1000, 1000)
for index := range s {
s[index] = index
}
}
func main() {
InitSlice()
}执行go build -gcflags=-m escape_b.go
# command-line-arguments
./escape_b.go:11:6: can inline main
./escape_b.go:4:11: make([]int, 1000, 1000) does not escape此时并没有发生逃逸
将切片的容量增大10倍,即:
package main
func InitSlice() {
s := make([]int, 1000, 10000)
for index := range s {
s[index] = index
}
}
func main() {
InitSlice()
}执行go build -gcflags=-m escape_b.go
# command-line-arguments
./escape_b.go:11:6: can inline main
./escape_b.go:4:11: make([]int, 1000, 10000) escapes to heap发生了逃逸
当栈空间不足以存放当前对象,或无法判断当前切片长度时,会将对象分配到堆中
ps:
package main
func InitSlice() {
s := make([]int, 1000, 1000)
for index := range s {
s[index] = index
}
println(s)
}
func main() {
InitSlice()
}执行go build -gcflags=-m escape_b.go
# command-line-arguments
./escape_b.go:12:6: can inline main
./escape_b.go:4:11: make([]int, 1000, 1000) does not escape没有逃逸.
而改成
package main
import "fmt"
func InitSlice() {
s := make([]int, 1000, 1000)
for index := range s {
s[index] = index
}
fmt.Println(s)
}
func main() {
InitSlice()
}执行go build -gcflags=-m escape_b.go,则
# command-line-arguments
./escape_b.go:11:13: inlining call to fmt.Println
./escape_b.go:14:6: can inline main
./escape_b.go:6:11: make([]int, 1000, 1000) escapes to heap
./escape_b.go:11:13: s escapes to heap
./escape_b.go:11:13: []interface {}{...} does not escape
:1: .this does not escape 发生了逃逸
这是为何? 参见下文!
3. 动态类型逃逸(不确定长度大小):
当函数参数为interface{}类型, 如最常用的fmt.Println(a …interface{}), 编译期间很难确定其参数的具体类型,也会产生逃逸
对于 escape_c1.go:
package main
import "fmt"
func main() {
s := "s会发生逃逸"
fmt.Println(s)
}执行go build -gcflags=-m escape_c1.go
# command-line-arguments
./escape_c1.go:7:13: inlining call to fmt.Println
./escape_c1.go:7:13: s escapes to heap
./escape_c1.go:7:13: []interface {}{...} does not escape
:1: .this does not escape 对于 escape_c1.go:
package main
func main() {
InitSlice2()
}
func InitSlice2() {
a := make([]int, 0, 20) // 栈 空间小
b := make([]int, 0, 20000) // 堆 空间过大 逃逸
l := 20
c := make([]int, 0, l) // 堆 动态分配不定空间 逃逸
_, _, _ = a, b, c
}执行go build -gcflags=-m escape_c2.go
# command-line-arguments
./escape_c2.go:7:6: can inline InitSlice2
./escape_c2.go:3:6: can inline main
./escape_c2.go:4:12: inlining call to InitSlice2
./escape_c2.go:4:12: make([]int, 0, 20) does not escape
./escape_c2.go:4:12: make([]int, 0, 20000) escapes to heap
./escape_c2.go:4:12: make([]int, 0, l) escapes to heap
./escape_c2.go:8:11: make([]int, 0, 20) does not escape
./escape_c2.go:9:11: make([]int, 0, 20000) escapes to heap
./escape_c2.go:12:11: make([]int, 0, l) escapes to heap4. 闭包引用对象逃逸:
对于如下斐波那契数列escape_d.go:
package main
import "fmt"
func Fibonacci() func() int {
a, b := 0, 1
return func() int {
a, b = b, a+b
return a
}
}
func main() {
f := Fibonacci()
for i := 0; i < 10; i++ {
fmt.Printf("Fibonacci: %d\n", f())
}
}执行go build -gcflags=-m escape_d.go
# command-line-arguments
./escape_d.go:7:9: can inline Fibonacci.func1
./escape_d.go:17:13: inlining call to fmt.Printf
./escape_d.go:6:2: moved to heap: a
./escape_d.go:6:5: moved to heap: b
./escape_d.go:7:9: func literal escapes to heap
./escape_d.go:17:34: f() escapes to heap
./escape_d.go:17:13: []interface {}{...} does not escape
:1: .this does not escape Fibonacci()函数中原本属于局部变量的a和b,由于闭包的引用,不得不将二者放到堆上,从而产生逃逸
总结
- 逃逸分析在编译阶段完成
- 逃逸分析目的是决定内分配地址是栈还是堆
- 栈上分配内存比在堆中分配内存有更高的效率
- 栈上分配的内存不需要GC处理
- 堆上分配的内存使用完毕会交给GC处理
通过逃逸分析,不逃逸的对象分配在栈上,当函数返回时就回收了资源,不需gc标记清除,从而减少gc的压力
同时,栈的分配比堆快,性能好(逃逸的局部变量会在堆上分配,而没有发生逃逸的则有编译器在栈上分配)
另外,还可以进行同步消除: 如果定义的对象的方法上有同步锁,但在运行时却只有一个线程在访问,此时逃逸分析后的机器码会去掉同步锁运行
全文参考自:
推荐阅读:
本文由mdnice多平台发布