
内存管理主要包括两个动作:分配与释放。逃逸分析就是服务于内存分配的,而内存的释放由GC负责。
在Go语言中,栈的内存是由编译器自动进行分配和释放的,栈区往往存储着函数参数、局部变量和调用函数帧,它们随着函数的创建而分配,随着函数的退出而销毁。
Go应用程序运行时,每个 goroutine 都维护着一个自己的栈区,这个栈区只能自己使用不能被其他 goroutine 使用。栈是调用栈(call stack)的简称。一个栈通常又包含了许多栈帧(stack frame),它描述的是函数之间的调用关系
与栈不同的是,堆区的内存一般由编译器和工程师自己共同进行管理分配,交给 Runtime GC 来释放。在堆上分配时,必须找到一块足够大的内存来存放新的变量数据。后续释放时,垃圾回收器扫描堆空间寻找不再被使用的对象。
我们可以简单理解为:我们用GO语言开发过程中,要考虑的内存管理只是针对堆内存而言的。
程序在运行期间可以主动从堆上申请内存,这些内存通过Go的内存分配器分配,并由垃圾收集器回收。
为了方便大家理解,我们再从以下角度对比一下堆栈:
延伸知识点:为什么堆上的内存有时需要加锁?而不是一直需要加锁呢?
因为Go的内存分配策略学习了TCMalloc的线程缓存思想,他为每个处理器分配了一个mcache,注意:从mcache分配内存也是无锁的。
延伸知识点:为什么堆上的内存有时需要加锁?而不是一直需要加锁呢?
因为Go的内存分配策略学习了TCMalloc的线程缓存思想,他为每个处理器分配了一个mcache,注意:从mcache分配内存也是无锁的。
原因是:栈内存能更好地利用CPU的缓存策略,因为栈空间相较于堆来说是更连续的。
相比于把内存分配到堆中,分配到栈中优势更明显。
Go语言也是这么做的:Go编译器会尽可能将变量分配到到栈上。
但是,在函数返回后无法证明变量未被引用,则该变量将被分配到堆上,该变量不随函数栈的回收而回收。以此避免悬挂指针(dangling pointer)的问题。
另外,如果局部变量占用内存非常大,也会将其分配在堆上。
Go是如何确定内存是分配到栈上还是堆上的呢?
答案就是:逃逸分析。
编译器通过逃逸分析技术去选择堆或者栈,逃逸分析的基本思想如下:检查变量的生命周期是否是完全可知的,如果通过检查,则在栈上分配。否则,就是所谓的逃逸,必须在堆上进行分配。
逃逸分析原则:
Go语言虽然没有明确说明逃逸分析原则,但是有以下几点准则,是可以参考的。
举个日常开发中函数传参例子:
有些场景下我们不应该传递结构体指针,而应该直接传递结构体。
为什么会这样呢?虽然直接传递结构体需要值拷贝,但是这是在栈上完成的操作,开销远比变量逃逸后动态地在堆上分配内存少的多。
当然这种做法不是绝对的,要根据场景去分析: