Golang 逃逸分析（Escape Analysis）理解与实践篇

逃逸分析（Escape Analysis）是编译器在编译期进行的一项优化技术，是Glang非常重要的性能优化工具。其目的是判断某个变量是否会被函数外部引用，或者超出其作用范围。

1.逃逸分析

如果变量仅在函数内部使用，那么它可以安全地分配在栈上；如果变量“逃逸”到函数外部（例如返回给调用者或者传递给其他协程），编译器会将其分配到堆上，以保证其生命周期不会在栈帧结束时被销毁。

1.返回指针：如果函数返回了局部变量的指针，该变量就会逃逸到堆上。
2.闭包捕获变量：闭包函数中捕获的外部变量也会导致变量逃逸。
3.接口类型的转换：接口转换时，如果具体类型需要被持久化存储，那么它可能逃逸。
4.动态分配的内存：例如使用 new 或者 make 创建的对象，编译器可能会决定将它们分配在堆上。
5.使用 Goroutine ：需要特别注意变量逃逸问题。因为 Goroutine 会并发执行，某些变量可能在 Goroutine 中被引用，导致它们逃逸到堆上。

Golang 提供了逃逸分析的工具（编译时查看函数中哪些变量发生了逃逸）：

go build -gcflags="-m"

---

2.相关知识（栈、堆、GC分析）

栈分配：栈是 Go 中快速分配和释放内存的区域。栈上的变量在函数返回时自动销毁，不需要额外的垃圾回收（GC）开销。
堆分配：堆上的内存分配速度相对较慢，且需要依赖 Go 的垃圾回收机制进行管理。频繁的堆分配会导致 GC 的频率增加，从而影响性能。
GC：Go 的垃圾回收器是三色标记清除算法，每次垃圾回收会对堆上的所有对象进行追踪和标记，回收不再使用的内存。

• 白色（待回收）：白色的对象表示未被访问到的对象。在垃圾回收开始时，所有的对象最初都被标记为白色。最终，所有仍然是白色的对象将被认定为不可达的，并在清除阶段被回收。
• 灰色（待处理）：灰色的对象表示已经被垃圾回收器访问到，但其引用的对象还没有完全处理。灰色对象需要进一步追踪其引用的对象。
• 黑色（已处理）：黑色的对象表示已经被处理过，它的引用对象也已经被追踪，不会被再次检查。黑色对象是安全的，表示它们依然在使用，不会被回收。

启用 GC 配置：

export GOGC=50 # 设置 GOGC 为 50，增加 GC 频率，降低内存占用
export GODEBUG=gctrace=1  # GC 运行的详细信息，包括 GC 触发的时机、暂停时间、以及每次回收时清理的内存量

GC 测试 demo：

package mainimport ("fmt""runtime""time"
)func main() {// 启动一个 Goroutine，持续分配内存，触发 GCgo func() {for {_ = make([]byte, 10<<20) // 每次分配 10MB 内存time.Sleep(100 * time.Millisecond)}}()// 打印内存使用情况和 GC 次数var m runtime.MemStatsfor i := 0; i < 10; i++ {runtime.ReadMemStats(&m)fmt.Printf("Alloc = %v MiB, Sys = %v MiB, NumGC = %v\n", m.Alloc/1024/1024, m.Sys/1024/1024, m.NumGC)time.Sleep(1 * time.Second)}
}

---

3.逃逸分析综合-实践 demo

package mainimport ("fmt""runtime"
)// 示例1：返回局部变量的指针
func escapeToHeap() *int {a := 42return &a // 逃逸到堆上，因为返回了局部变量的指针
}// 示例2：闭包捕获外部变量
func closureExample() func() int {x := 100return func() int {return x // x 逃逸到堆上，闭包捕获了外部变量}
}// 示例3：接口转换导致逃逸
func interfaceExample() {var i interface{}i = 42  // 逃逸到堆上，因为 interface 可能会持有较大对象fmt.Println(i)
}// 示例4：动态分配内存
func dynamicAllocation() {p := new(int) // 逃逸到堆上，使用 new 分配内存*p = 42fmt.Println(*p)
}// 示例5：在栈上分配
func noEscape() {x := 42 // 没有逃逸，x 在栈上分配fmt.Println(x)
}// 示例6：Goroutine 中的逃逸分析
func goroutineEscape() {x := 42go func() {fmt.Println(x) // x 逃逸到堆上，因为被 Goroutine 使用}()
}func main() {// 打印当前内存使用情况var m runtime.MemStatsruntime.ReadMemStats(&m)fmt.Printf("Initial Alloc = %v KB\n", m.Alloc/1024)// 测试逃逸分析的各个示例fmt.Println("Running escapeToHeap()")escapeToHeap()fmt.Println("Running closureExample()")closure := closureExample()fmt.Println(closure())fmt.Println("Running interfaceExample()")interfaceExample()fmt.Println("Running dynamicAllocation()")dynamicAllocation()fmt.Println("Running noEscape()")noEscape()fmt.Println("Running goroutineEscape()")goroutineEscape()// 打印最终内存使用情况runtime.ReadMemStats(&m)fmt.Printf("Final Alloc = %v KB\n", m.Alloc/1024)
}

编译-逃逸分析

[jn@jn ~]$ go build -gcflags="-m" escape.go
# command-line-arguments
./escape.go:9:6: can inline escapeToHeap
./escape.go:15:6: can inline closureExample
./escape.go:17:9: can inline closureExample.func1
./escape.go:26:13: inlining call to fmt.Println
./escape.go:33:13: inlining call to fmt.Println
./escape.go:39:13: inlining call to fmt.Println
./escape.go:45:5: can inline goroutineEscape.func1
./escape.go:46:14: inlining call to fmt.Println
./escape.go:54:12: inlining call to fmt.Printf
./escape.go:57:13: inlining call to fmt.Println
./escape.go:58:14: inlining call to escapeToHeap
./escape.go:60:13: inlining call to fmt.Println
./escape.go:61:27: inlining call to closureExample
./escape.go:17:9: can inline main.func1
./escape.go:62:21: inlining call to main.func1
./escape.go:62:13: inlining call to fmt.Println
./escape.go:64:13: inlining call to fmt.Println
./escape.go:67:13: inlining call to fmt.Println
./escape.go:70:13: inlining call to fmt.Println
./escape.go:73:13: inlining call to fmt.Println
./escape.go:78:12: inlining call to fmt.Printf
./escape.go:10:2: moved to heap: a
./escape.go:17:9: func literal escapes to heap
./escape.go:25:2: 42 escapes to heap
./escape.go:26:13: ... argument does not escape
./escape.go:31:10: new(int) does not escape
./escape.go:33:13: ... argument does not escape
./escape.go:33:14: *p escapes to heap
./escape.go:39:13: ... argument does not escape
./escape.go:39:13: x escapes to heap
./escape.go:45:5: func literal escapes to heap
./escape.go:46:14: ... argument does not escape
./escape.go:46:14: x escapes to heap
./escape.go:54:12: ... argument does not escape
./escape.go:54:47: m.Alloc / 1024 escapes to heap
./escape.go:57:13: ... argument does not escape
./escape.go:57:14: "Running escapeToHeap()" escapes to heap
./escape.go:60:13: ... argument does not escape
./escape.go:60:14: "Running closureExample()" escapes to heap
./escape.go:61:27: func literal does not escape
./escape.go:62:13: ... argument does not escape
./escape.go:62:21: ~R0 escapes to heap
./escape.go:64:13: ... argument does not escape
./escape.go:64:14: "Running interfaceExample()" escapes to heap
./escape.go:67:13: ... argument does not escape
./escape.go:67:14: "Running dynamicAllocation()" escapes to heap
./escape.go:70:13: ... argument does not escape
./escape.go:70:14: "Running noEscape()" escapes to heap
./escape.go:73:13: ... argument does not escape
./escape.go:73:14: "Running goroutineEscape()" escapes to heap
./escape.go:78:12: ... argument does not escape
./escape.go:78:45: m.Alloc / 1024 escapes to heap
[jn@jn ~]$

run

[jn@jn ~]$ ./escape
Initial Alloc = 187 KB
Running escapeToHeap()
Running closureExample()
100
Running interfaceExample()
42
Running dynamicAllocation()
42
Running noEscape()
42
Running goroutineEscape()
Final Alloc = 190 KB
[jn@jn ~]$

end

1.尽量避免将局部变量的指针返回给外部。
2.使用闭包时注意外部变量的捕获，避免逃逸。
3.尽量减少接口类型和 Goroutine 导致的逃逸。