在C/C++里面 变量分配在栈和堆是有区别的，简而言之吗，通常变量分配在栈上会随着函数释放而释放，变量分配在堆上则不会随函数返回而释放。然而在golang里面这种写法确是能够的。
一般在编译代码的时候，编译器根据分析，判断将变量分配在栈或堆上。函数定义中，通常将局部变量和参数分配到栈上（stack frame）上。可是，若是编译器不能肯定在函数返回（return）时，变量是否被引用（reference），分配到堆上；若是局部变量很是大，也应分配在堆上。golang
若是对变量取地址（*和&操做），则有可能分配在堆上。此外，还须要进行逃逸分析（escape analytic），判断return后变量是否被引用，不引用分配到栈上，引用分配到堆上。编程
在golang中逃逸分析是一种肯定指针动态范围的方法，能够分析在程序的哪些地方能够访问到指针。它涉及到指针分析和形状分析。当一个变量(或对象)在子程序中被分配时，一个指向变量的指针可能逃逸到其它执行线程中，或者去调用子程序。若是使用尾递归优化（一般在函数编程语言中是须要的），对象也可能逃逸到被调用的子程序中。 若是一个子程序分配一个对象并返回一个该对象的指针，该对象可能在程序中的任何一个地方被访问到——这样指针就成功“逃逸”了。若是指针存储在全局变量或者其它数据结构中，它们也可能发生逃逸，这种状况是当前程序中的指针逃逸。 逃逸分析须要肯定指针全部能够存储的地方，保证指针的生命周期只在当前进程或线程中。安全
可是golang 编译器决定变量应该分配到什么地方时会进行逃逸分析，下面咱们看段代码：数据结构
package main编程语言
import ()ide
func foo() *int {
var x int
return &x
}函数
func bar() int {
x := new(int)
*x = 1
return *x
}性能
func main() {}优化
运行后:线程
> go run -gcflags '-m -l' escape.go ./main.go:6: moved to heap: x ./main.go:7: &x escape to heap ./main.go:11: bar new(int) does not escape
foo() 中的 x 最后在堆上分配，而 bar() 中的 x 最后分配在了栈上。在官网 (golang.org) FAQ 上有一个关于变量分配的问题以下：
如何得知变量是分配在栈（stack）上仍是堆（heap）上？
准确地说，你并不须要知道。Golang 中的变量只要被引用就一直会存活，存储在堆上仍是栈上由内部实现决定而和具体的语法没有关系。
知道变量的存储位置确实和效率编程有关系。若是可能，Golang 编译器会将函数的局部变量分配到函数栈帧（stack frame）上。 然而，若是编译器不能确保变量在函数 return以后再也不被引用，编译器就会将变量分配到堆上。并且，若是一个局部变量很是大，那么它也应该被分配到堆上而不是栈上。
当前状况下，若是一个变量被取地址，那么它就有可能被分配到堆上。然而，还要对这些变量作逃逸分析，若是函数return以后，变量再也不被引用，则将其分配到栈上。
其实在golang中全部静态内存的其实分配都是在 stack 上进行的，而函数体在执行结束出栈后全部在栈上分配的内存都将获得释放，若是此时直接返回当前做用域变量的指针，这在下层函数的寻址行为就会由于出栈的内存释放而形成空指针异常。这个时候咱们就得须要用到malloc在堆上(heap)动态分配内存，本身管理内存的生命周期，本身手动释放才是安全的方式。
然而escape analysis的存在让go完美规避了这些问题，编译器在编译时对代码作了分析，若是发现当前做用域的变量没有超出函数范围，则会自动在stack上分配，若是找不到了，则会在heap上分配。这样其实开发者就不用太关心堆栈的使用边界，在代码层面上彻底不须要关心内存的分配，把底层要考虑的问题交给编译器，同时也减少了gc回收的压力。
go在必定程度消除了堆和栈的区别，由于go在编译的时候进行逃逸分析，来决定一个对象放栈上仍是放堆上，不逃逸的对象放栈上，可能逃逸的放堆上。
那么逃逸分析的做用是什么呢？
1.逃逸分析的好处是为了减小gc的压力，不逃逸的对象分配在栈上，当函数返回时就回收了资源，不须要gc标记清除。
2.逃逸分析完后能够肯定哪些变量能够分配在栈上，栈的分配比堆快，性能好(逃逸的局部变量会在堆上分配 ,而没有发生逃逸的则有编译器在栈上分配)。
3.同步消除，若是你定义的对象的方法上有同步锁，但在运行时，却只有一个线程在访问，此时逃逸分析后的机器码，会去掉同步锁运行。
咱们在开发的时候其实也能够本身去设置和查看逃逸分析的log，咱们能够分析逃逸日志，只要在编译的时候加上-gcflags '-m'，可是咱们为了避免让编译时自动内连函数，通常会加-l参数，最终为-gcflags '-m -l'.在main中能够用:
go run -gcflags '-m -l' main.go
那么接着就会有个问题何时会逃逸，何时不会逃逸呢？
接下来咱们看个例子：
`package main
type Elegance struct{}
func main() {
var e Elegance
p := &e
_ = *identity(y)
}
func identity(m *Elegance) *Elegance {
return m
}运行后：main.go:11: leaking param: m to result ~r1 level=0
main.go:7: main &e does not escape`
在这里的m变量是“流式”，由于identity这个函数仅仅输入一个变量，又将这个变量做为返回输出，但identity并无引用m，因此这个变量没有逃逸，而e没有被引用，且生命周期也在mian里，e没有逃逸，分配在栈上。
一般在go中函数都是运行在栈上的，在栈声明临时变量分配内存，函数运行完毕在回收该段栈空间，而且每一个函数的栈空间都是独立的，不能被访问到的。可是在某些状况下，栈上的空间须要在该函数被释放后依旧能访问到，这时候就涉及到内存的逃逸了。
`type data struct {
name string
}
func patent1()data{
p := data{"keke"}
return p
}
func patent2() *data {
p := data{"jame"}
return &p
}
func main(){
p1 := patent1()
p2 := patent2()
}`
这里的patent1和patent2函数都有返回值，惟一不一样的地方是patent1返回data结构体，patent2返回data结构体指针。在大多数语言例如C相似patent2的函数是不对的，由于p是一个临时变量，返回事后就会被释放掉，返回毫无心义。可是在golang中，这种语法是容许的，它能正确的把p的地址返回到上层调用函数而不被释放。
这样该函数在运行完毕后确定是要释放的，内部分配的临时内存也要释放，因此p也应该被释放。而为了让p能被正确返回到上层调用，golang采起了一种内存策略，把p从栈拿到堆的中去，此时p就不会跟随patent2一同消亡了，这个过程就是逃逸。