编译上述代码：main.cpp: In function ‘int* getValue()’: main.cpp:7:9: warning: address of local variable ‘val’ returned [-Wreturn-local-addr]
用同样的思想，写一个go版本的代码：
package main import ( "fmt" ) func main() { str := GetString() fmt.Println(*str) } func GetString() *string { var s string s = "hello world" return &s }代码却可以正常运行，我们本意是在栈上分配一个变量，用完就销毁，但是外部却调用了，甚至可以正常进行，表现和C++完全不同。
其实，这就是Go的内存逃逸现象，Go模糊了栈内存和堆内存的界限，具体来说变量究竟分配到哪里，是由编译器来决定的。
1逃逸分析escape analysis
所谓逃逸分析就是在编译阶段由编译器根据变量的类型、外部使用情况等因素来判定是分配到堆还是栈，从而替代人工处理。
一般将局部变量和参数分配到栈上，但是并不绝对：
编译器不清楚局部变量是否会被外部使用时，就会倾向于分配到堆上。
Go编译器在确定函数返回后不会再被引用时才分配到栈上，其他情况下都是分配到堆上。
这样做虽然浪费堆空间，但是有效避免了悬挂指针的出现，并且由于GC的存在也不会出现内存泄漏，权衡之下也是一种合理的做法。
2哪些情况会出现内存逃逸
对于Go来说，在日常使用中有几种常见的做法会导致内存逃逸现象的出现：
指针逃逸
在上一个例子中我们使用一个int指针来说明内存逃逸的现象，接下来我们扩展一下变为结构体指针，并且使用gcflags来给编译器传特定参数来观察逃逸现象：
// test.go package main import "fmt" type Escape struct { who string } func CallInstance(caller string) (*Escape) { instance := new(Escape) instance.who = caller return instance } func main() { outer := CallInstance("hello world") fmt.Println(outer.who) }执行：go build -gcflags=-m test.go 如下：
# command-line-arguments ./test.go:9:6: can inline CallInstance ./test.go:16:23: inlining call to CallInstance ./test.go:17:13: inlining call to fmt.Println ./test.go:9:19: leaking param: caller ./test.go:10:17: new(Escape) escapes to heap ./test.go:16:23: main new(Escape) does not escape ./test.go:17:19: outer.who escapes to heap ./test.go:17:13: main []interface {} literal does not escape ./test.go:17:13: io.Writer(os.Stdout) escapes to heap :1: (*File).close .this does not escape我们可以看到"escapes to heap"，确实出现了内存逃逸，本该在栈上逃逸到堆上了。
栈空间不足逃逸
对于64bit的Linux系统而言栈的大小一般是8MB，Go中每个goroutine初始化栈大小是2KB，在goroutine的运行过程中栈的大小可能会变化，但也不会超过OS对线程栈大小的限制。
在网上找了个例子，用mac跑了一下：
package main import "math/rand" func generate8191() { nums := make([]int, 8191) // < 64KB for i := 0; i < 8191; i++ { nums[i] = rand.Int() } } func generate8192() { nums := make([]int, 8192) // = 64KB for i := 0; i < 8192; i++ { nums[i] = rand.Int() } } func generate(n int) { nums := make([]int, n) // 不确定大小 for i := 0; i < n; i++ { nums[i] = rand.Int() } } func main() { generate8191() generate8192() generate(1) }# command-line-arguments ./test_3.go:6:14: generate8191 make([]int, 8191) does not escape ./test_3.go:13:14: make([]int, 8192) escapes to heap ./test_3.go:20:14: make([]int, n) escapes to heap
可以看到在分配8191个大小时未发生逃逸，在分配8192时发生了逃逸，不定长度也发生了逃逸。
其他情况
在go中map、interface、slice、interface是非常常见的数据结构，也是非常容易触发内存逃逸的根源。
向channel中发送指针或者带指针的值，因为在编译时没有办法知道哪个goroutine会在channel上接收数据。所以编译器没法知道变量什么时候才会被释放。
slice中指针或带指针的值，这会导致切片的内容逃逸，尽管其后面的数组可能是在栈上分配的，但其引用的值一定是在堆上。
slice数组扩容也可能导致内存逃逸，如果切片背后的存储要基于运行时的数据进行扩充，就会在堆上分配。
interface类型可以代表任意类型，编译器不知道参数会是什么类型，只有运行时才知道，因此只能分配到堆上。
Part3内存逃逸小结
我们该如何评价内存逃逸呢?
Go语言对用户来说模糊了堆内存和栈内存的分配，编译器借助于逃逸分析来实现特定场景的内存逃逸。
任何事情都是两面性，Go语言借助于内存逃逸和GC机制解放了程序员，但是同时也带来了性能问题，因为堆内存的分配和释放都是需要成本的。
Go的编译器在很多时候无法确定该如何分配内存，因此只能采用一种稳妥但有失性能的做法，分配到堆上。
意识里指针传递比值传递更高效，但是在Go中并非如此，如果指针传递出现内存逃逸将内存分配到堆上后续就有会GC操作，消耗比值传递更大。
如果明确不需要外部使用，就需要尽量避免内存逃逸，不要一味完全依赖编译器本身。
以上是“Go语言内存逃逸的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！
网页标题：Go语言内存逃逸的示例分析
网页地址：http://kswjz.com/article/jisssh.html
