一、堆、栈基本概念
Go 有两个地方可以分配内存：一个全局堆空间用来动态分配内存，另一个是每个 goroutine 都有的自身栈空间。
-
堆
堆区的内存一般由编译器和工程师自己共同进行管理分配，交给 Runtime GC 来释放。堆上分配必须找到一块足够大的内存来存放新的变量数据。后续释放时，垃圾回收器扫描堆空间寻找不再被使用的对象。 -
栈
栈区的内存一般由编译器自动进行分配和释放，其中存储着函数的入参以及局部变量，这些参数会随着函数的创建而创建，函数的返回而销毁。(通过 CPU push & release)。
go语言将变量分配到堆上还是栈上，取决于以下两点：
- 在函数返回后无法证明变量未被引用，则该变量将被分配到堆上，该变量不随函数栈的回收而回收
- 如果局部变量非常大，将它存储在堆而不是栈上可能更有意义
变量分配到栈上的优点：
- 减少 GC 压力，栈上的变量，随着函数退出后系统直接回收，不需要标记后再清除
- 减少内存碎片的产生
- 减轻分配堆内存的开销，提高程序的运行速度
goroutine的栈结构，详见以下源码：
// Stack describes a Go execution stack.
// The bounds of the stack are exactly [lo, hi),
// with no implicit data structures on either side.
type stack struct {
lo uintptr
hi uintptr
}
type g struct {
// Stack parameters.
// stack describes the actual stack memory: [stack.lo, stack.hi).
// stackguard0 is the stack pointer compared in the Go stack growth prologue.
// It is stack.lo+StackGuard normally, but can be StackPreempt to trigger a preemption.
// stackguard1 is the stack pointer compared in the C stack growth prologue.
// It is stack.lo+StackGuard on g0 and gsignal stacks.
// It is ~0 on other goroutine stacks, to trigger a call to morestackc (and crash).
stack stack // offset known to runtime/cgo
stackguard0 uintptr // offset known to liblink
stackguard1 uintptr // offset known to liblink
栈是由[lo, hi)描述的一块内存空间
stack.lo: 栈空间的低地址
stack.hi: 栈空间的高地址
stackguard0: stack.lo + StackGuard, 用于stack overlow的检测
StackGuard: 保护区大小，常量Linux上为880字节
StackSmall: 常量大小为128字节，用于小函数调用的优化
二、逃逸分析
逃逸分析：是“通过检查变量的作用域是否超出了它所在的栈来决定是否将它分配在堆上”的技术，其中“变量的作用域超出了它所在的栈”这种行为即被称为逃逸。
我们在 go build 编译代码时，可使用 -gcflags '-m' 参数来查看逃逸分析日志。
go build -gcflags "-m -m" test.go
需要使用堆空间则逃逸，这没什么可争议的。但编译器为了保证内存的绝对安全，有时会将不需要使用堆空间的变量，也逃逸掉。这里是容易出现性能问题的大坑。网上有很多相关文章，列举了一些导致逃逸情况，其实总结起来就一句话：
多级间接赋值容易导致逃逸。
这里的多级间接指的是，对某个引用类对象中的引用类成员进行赋值。Go 语言中的引用类数据类型有 func, interface, slice, map, chan, *Type(指针)。
记住公式 Data.Field = Value，如果 Data, Field 都是引用类的数据类型，则会导致 Value 逃逸。这里的等号 = 不单单只赋值，也表示参数传递。
根据公式，我们假设一个变量 data 是以下几种类型，相应的可得出结论：
[]interface{}: data[0] = 100会导致100逃逸
map[string]interface{}: data["key"] = "value"会导致"value"逃逸
map[interface{}]interface{}: data["key"] = "value"会导致key和value都逃逸
map[string][]string: data["key"] = []string{"hello"}会导致切片逃逸
map[string]*int: 赋值时*int会 逃逸
[]*int: data[0] = &i会使i逃逸
func(*int): data(&i)会使i逃逸
func([]string): data([]{"hello"})会使[]string{"hello"}逃逸
chan []string: data <- []string{"hello"}会使[]string{"hello"}逃逸
......
以此类推，不一一列举了
多级间接赋值会导致 Go 编译器出现不必要的逃逸，在一些情况下可能我们只需要修改一下数据结构就会使性能有大幅提升。这也是很多人不推荐在 Go 中使用指针的原因，因为它会增加一级访问路径，而 map, slice, interface{}等类型是不可避免要用到的，为了减少不必要的逃逸，只能拿指针开刀了。
一般情况下我们会这样认为：“值的拷贝是昂贵的，所以用一个指针来代替。”
但是，在很多情况下，直接的值拷贝要比使用指针廉价的多。你可能要问为什么。
编译器会在解除指针时做检查。
目的是在指针是 nil 的情况下直接 panic() 以避免内存泄露。这就必须在运行时执行更多的代码。如果数据是按值传递的，那就不需要做这些了，它不可能是 nil指针通常有糟糕的局部引用。
一个函数内部的所有值都会在栈空间上分配。局部引用是编写高效代码的重要环节。它会使得变量数据在 CPU Cache(cpu 的一级二级缓存) 中的热度更高，进而减少指令预取时 Cache 不命中的的几率。在Cache层拷贝一堆对象，可粗略地认为和拷贝一个指针效率是一样的。
CPU 在各 Cache 层和主内存中以固定大小的 cache 进行内存移动。x86 机器上是 64 字节。而且，Go 使用了Duff’s device 技术来使得常规内存操作变得更高效。
减少程序中指针的使用的另一个好处是，如果可以证明它里面没有指针，垃圾回收器会直接越过这块内存。
减少指针的使用不仅可以降低垃圾回收的工作量，它会产生对 cache 更加友好的代码。读内存是要把数据从主内存读到 CPU 的 cache 中。
大多数情况下，性能优化都会为程序带来一定的复杂度。建议实际项目中还是怎么方便怎么写，功能完成后通过性能分析找到瓶颈所在，再对局部进行优化。
三、分段栈&连续栈
Go 应用程序运行时，每个 goroutine 都维护着一个自己的栈区，这个栈区只能自己使用不能被其他 goroutine 使用。栈区的初始大小是 2KB(比 x86_64 架构下线程的默认栈2M 要小很多)，在 goroutine 运行的时候栈区会按照需要增长和收缩，占用的内存最大限制的默认值在 64 位系统上是 1GB。
- v1.0 ~ v1.1 — 最小栈内存空间为 4KB；
- v1.2 — 将最小栈内存提升到了 8KB；
- v1.3 — 使用连续栈替换之前版本的分段栈；
- v1.4 — 将最小栈内存降低到了 2KB；
1. 分段栈
Go 1.3 版本前使用的栈结构是分段栈。随着goroutine 调用的函数层级的深入或者局部变量需要的越来越多时，运行时会调用 runtime.morestack 和 runtime.newstack创建一个新的栈空间，这些栈空间是不连续的，但是当前 goroutine 的多个栈空间会以双向链表的形式串联起来，运行时会通过指针找到连续的栈片段：
分段栈虽然能够按需为当前 goroutine 分配内存并且及时减少内存的占用，但是它却存在热分裂（Hot Split）的问题。如果栈快满了，那么下一次的函数调用会强制触发栈扩容。当函数返回时，新分配的 “stackchunk” 会被清理掉。如果这个函数调用产生的范围是在一个循环中，会导致严重的性能问题，频繁的 alloc/free，如下图所示：
Go 不得不在 1.2 版本把栈默认大小改为 8KB，降低触发热分裂的问题，但是每个 goroutine内存开销就比较大了。直到实现了连续栈(contiguous stack)，栈大小才改为2KB。
2. 连续栈
采用复制栈的实现方式，在热分裂场景中不会频发释放内存，即不像分配一个新的内存块并链接到老的栈内存块，而是会分配一个两倍大的内存块并把老的内存块内容复制到新的内存块里，当栈缩减回之前大小时，我们不需要做任何事情。
使用连续栈机制时，栈空间不足导致的扩容会经历以下几个步骤：
- 调用
runtime.newstack在内存空间中分配更大的栈内存空间； - 使用
runtime.copystack将旧栈中的所有内容复制到新的栈中； - 将指向旧栈对应变量的指针重新指向新栈；
- 调用
runtime.stackfree销毁并回收旧栈的内存空间。
copystack会把旧栈里的所有内容拷贝到新栈里然后调整所有指向旧栈的变量的指针指向到新栈， 栈扩容后同一个变量的内存地址会发生变化。
如果栈区的空间使用率不超过 1/4，那么在垃圾回收的时候使用runtime.shrinkstack进行栈缩容，最后同样使用runtime.copystack将旧栈中的所有内容复制到新的栈中。
四、栈的操作
1. 栈的初始化
栈空间在运行时中包含两个重要的全局变量，分别是 runtime.stackpool 和 runtime.stackLarge，这两个变量分别表示全局的栈缓存和大栈缓存，前者可以分配小于 32KB 的内存，后者用来分配大于 32KB 的栈空间：
var stackpool [_NumStackOrders]struct {
item stackpoolItem
_ [cpu.CacheLinePadSize - unsafe.Sizeof(stackpoolItem{})%cpu.CacheLinePadSize]byte
}
//go:notinheap
type stackpoolItem struct {
mu mutex
span mSpanList
}
var stackLarge struct {
lock mutex
free [heapAddrBits - pageShift]mSpanList
}
这两个用于分配空间的全局变量都与内存管理单元 runtime.mspan 有关，我们可以认为 Go 语言的栈内存都是分配在堆上的。所以我们栈内容的申请也是跟前面文章里的一样，先去当前线程的对应尺寸的mcache里去申请，不够的时候mache会从全局的mcental里取内存等等。
运行时初始化会调用 runtime.stackinit 初始化这些全局变量：
func stackinit() {
if _StackCacheSize&_PageMask != 0 {
throw("cache size must be a multiple of page size")
}
for i := range stackpool {
stackpool[i].item.span.init()
lockInit(&stackpool[i].item.mu, lockRankStackpool)
}
for i := range stackLarge.free {
stackLarge.free[i].init()
lockInit(&stackLarge.lock, lockRankStackLarge)
}
}
从调度器和内存分配的经验来看，如果运行时只使用全局变量来分配内存的话，势必会造成线程之间的锁竞争进而影响程序的执行效率，栈内存由于与线程关系比较密切，所以我们在每一个线程缓存 runtime.mcache 中都加入了栈缓存减少锁竞争影响。
type mcache struct {
......
stackcache [_NumStackOrders]stackfreelist
......
}
type stackfreelist struct {
list gclinkptr
size uintptr
}
2. 栈的分配
运行时会在 Goroutine 的初始化函数 runtime.malg 中调用 runtime.stackalloc 分配一个大小足够栈内存空间，根据线程缓存和申请栈的大小，该函数会通过三种不同的方法分配栈空间：
-
如果栈空间较小（<32KB），使用
runtime.stackpool或者mcache.stackcache上固定大小的空闲链表分配内存； -
如果栈空间较大，从全局的大栈缓存
runtime.stackLarge中获取内存空间； -
如果栈空间较大并且
runtime.stackLarge空间不足，在堆上申请一片大小足够内存空间；
栈空间分配源码如下：
func stackalloc(n uint32) stack {
thisg := getg()
var v unsafe.Pointer
// 在 Linux 上，_FixedStack = 2048、_NumStackOrders = 4、_StackCacheSize = 32768
if n < _FixedStack<<_NumStackOrders && n < _StackCacheSize {
order := uint8(0)
n2 := n
for n2 > _FixedStack {
order++
n2 >>= 1
}
var x gclinkptr
c := thisg.m.mcache
if stackNoCache != 0 || thisg.m.p == 0 || thisg.m.preemptoff != "" {
// stackNoCache => disable per-P small stack caches
// thisg.m.p == 0 => 会在exitsyscall或procresize内部发生
// if m.preemptoff != "", 保持g运行在当前m上
// runtime.stackpoolalloc会在全局的栈缓存池 runtime.stackpool中获取新的内存，
// 如果栈缓存池中不包含剩余的内存，运行时会从堆上申请一片内存空间
x = stackpoolalloc(order)
} else {
// 如果线程缓存中包含足够的空间，我们可以从线程本地的缓存中获取内存，
// 一旦发现空间不足就会调用 runtime.stackcacherefill从堆上获取新的内存。
x = c.stackcache[order].list
if x.ptr() == nil {
stackcacherefill(c, order)
x = c.stackcache[order].list
}
c.stackcache[order].list = x.ptr().next
c.stackcache[order].size -= uintptr(n)
}
v = unsafe.Pointer(x)
} else {
// 如果 Goroutine 申请的内存空间过大，运行时会查看 runtime.stackLarge中是否有剩余的空间，
// 如果不存在剩余空间，它也会从堆上申请新的内存
var s *mspan
npage := uintptr(n) >> _PageShift
log2npage := stacklog2(npage)
if !stackLarge.free[log2npage].isEmpty() {
s = stackLarge.free[log2npage].first
stackLarge.free[log2npage].remove(s)
}
if s == nil {
s = mheap_.allocManual(npage, &memstats.stacks_inuse)
osStackAlloc(s)
s.elemsize = uintptr(n)
}
v = unsafe.Pointer(s.base())
}
return stack{uintptr(v), uintptr(v) + uintptr(n)}
}
3. 栈的扩容
编译器会在 cmd/internal/obj/x86.stacksplit 中为函数调用插入 runtime.morestack 运行时检查，它会在几乎所有的函数调用之前检查当前 Goroutine 的栈内存是否充足。
go会根据以下条件判断函数是否需要插入morestack：
- 当函数是叶子节点，且栈帧小于等于 112 ，不插入指令
- 当叶子函数栈帧大小为 120 -128 或者 非叶子函数栈帧大小为 0 - 128，SP < stackguard0，插入指令
- 当函数栈帧大小为 128 - 4096 SP - framesize < stackguard0 - StackSmall，插入指令
- 大于 StackBig：SP-stackguard+StackGuard <= framesize + (StackGuardStackSmall)，插入指令
如果当前栈需要扩容，我们会保存一些栈的相关信息并调用 runtime.newstack 创建新的栈。
func newstack() {
thisg := getg()
gp := thisg.m.curg
...
preempt := atomic.Loaduintptr(&gp.stackguard0) == stackPreempt
if preempt {
if !canPreemptM(thisg.m) {
gp.stackguard0 = gp.stack.lo + _StackGuard
gogo(&gp.sched)
}
}
sp := gp.sched.sp
...
if preempt {
...
if gp.preemptShrink {
// We're at a synchronous safe point now, so
// do the pending stack shrink.
gp.preemptShrink = false
shrinkstack(gp)
}
if gp.preemptStop {
preemptPark(gp) // never returns
}
// Act like goroutine called runtime.Gosched.
gopreempt_m(gp) // never return
...
}
...
}
runtime.newstack 会先做一些准备工作并检查当前 Goroutine 是否发出了抢占请求，如果发出了抢占请求：
- 当前线程可以被抢占时，直接调用
runtime.gogo触发调度器的调度； - 如果当前 Goroutine 在垃圾回收被
runtime.scanstack标记成了需要收缩栈，调用runtime.shrinkstack； - 如果当前 Goroutine 被
runtime.suspendG函数挂起，调用runtime.preemptPark被动让出当前处理器的控制权并将 Goroutine 的状态修改至_Gpreempted； - 调用
runtime.gopreempt_m主动让出当前处理器的控制权；
如果当前 Goroutine 不需要被抢占，意味着我们需要新的栈空间来支持函数调用和本地变量的初始化，运行时会先检查目标大小的栈是否会溢出：
func newstack() {
...
oldsize := gp.stack.hi - gp.stack.lo
newsize := oldsize * 2
if newsize > maxstacksize {
print("runtime: goroutine stack exceeds ", maxstacksize, "-byte limit\n")
print("runtime: sp=", hex(sp), " stack=[", hex(gp.stack.lo), ", ", hex(gp.stack.hi), "]\n")
throw("stack overflow")
}
casgstatus(gp, _Grunning, _Gcopystack)
copystack(gp, newsize)
casgstatus(gp, _Gcopystack, _Grunning)
gogo(&gp.sched)
}
如果目标栈的大小没有超出程序的限制，我们会将 Goroutine 切换至 _Gcopystack 状态并调用 runtime.copystack 开始栈拷贝。在拷贝栈内存之前，运行时会通过 runtime.stackalloc 分配新的栈空间：
func copystack(gp *g, newsize uintptr) {
old := gp.stack
used := old.hi - gp.sched.sp
new := stackalloc(uint32(newsize))
...
}
新栈的初始化和数据的复制是一个比较简单的过程，不过这不是整个过程中最复杂的地方，我们还需要将指向源栈中内存指向新的栈，在这期间我们需要分别调整以下的指针：
- 调用
runtime.adjustsudogs或者runtime.syncadjustsudogs调整runtime.sudog（sudog是等待队列中的g，例如通过channe发送\接收数据）结构体的指针； - 调用
runtime.memmove将源栈中的整片内存拷贝到新的栈中； - 调用
runtime.adjustctxt、runtime.adjustdefers和runtime.adjustpanics调整剩余 Goroutine 相关数据结构的指针；
func copystack(gp *g, newsize uintptr) {
...
var adjinfo adjustinfo
adjinfo.old = old
adjinfo.delta = new.hi - old.hi // 计算新栈和旧栈之间内存地址差
ncopy := used
if !gp.activeStackChans {
adjustsudogs(gp, &adjinfo)
} else {
adjinfo.sghi = findsghi(gp, old)
ncopy -= syncadjustsudogs(gp, used, &adjinfo)
}
memmove(unsafe.Pointer(new.hi-ncopy), unsafe.Pointer(old.hi-ncopy), ncopy)
// Adjust remaining structures that have pointers into stacks.
// We have to do most of these before we traceback the new
// stack because gentraceback uses them.
adjustctxt(gp, &adjinfo)
adjustdefers(gp, &adjinfo)
adjustpanics(gp, &adjinfo)
gp.stack = new
gp.stackguard0 = new.lo + _StackGuard
gp.sched.sp = new.hi - used
gp.stktopsp += adjinfo.delta
// Adjust pointers in the new stack.
gentraceback(^uintptr(0), ^uintptr(0), 0, gp, 0, nil, 0x7fffffff, adjustframe, noescape(unsafe.Pointer(&adjinfo)), 0)
// free old stack
if stackPoisonCopy != 0 {
fillstack(old, 0xfc)
}
stackfree(old)
}
调整指向栈内存的指针都会调用 runtime.adjustpointer，该函数会利用 runtime.adjustinfo 计算的新栈和旧栈之间的内存地址差来调整指针。所有的指针都被调整后，我们就可以更新 Goroutine 的几个变量并通过 runtime.stackfree 释放原始栈的内存空间了。
4. 栈的缩容
runtime.shrinkstack 栈缩容时调用的函数，该函数的实现原理非常简单，其中大部分都是检查是否满足缩容前置条件的代码，核心逻辑只有以下这几行：
func shrinkstack(gp *g) {
...
oldsize := gp.stack.hi - gp.stack.lo
newsize := oldsize / 2
if newsize < _FixedStack {
return
}
avail := gp.stack.hi - gp.stack.lo
if used := gp.stack.hi - gp.sched.sp + _StackLimit; used >= avail/4 {
return
}
copystack(gp, newsize)
}
如果要触发栈的缩容，新栈的大小会是原始栈的一半，不过如果新栈的大小低于程序的最低限制 2KB，那么缩容的过程就会停止。
运行时只会在栈内存使用不足 1/4 时进行缩容，缩容也会调用扩容时使用的 runtime.copystack 开辟新的栈空间。
5. 栈的回收
在GC Mark过程中，调用markroot时，会触发dead Gs栈回收操作。
func markroot(gcw *gcWork, i uint32) {
switch {
...
case i == fixedRootFreeGStacks:
// Switch to the system stack so we can call
// stackfree.
systemstack(markrootFreeGStacks)
...
}
}
func markrootFreeGStacks() {
// Take list of dead Gs with stacks.
lock(&sched.gFree.lock)
list := sched.gFree.stack
sched.gFree.stack = gList{}
unlock(&sched.gFree.lock)
if list.empty() {
return
}
// Free stacks.
q := gQueue{list.head, list.head}
for gp := list.head.ptr(); gp != nil; gp = gp.schedlink.ptr() {
stackfree(gp.stack)
gp.stack.lo = 0
gp.stack.hi = 0
// Manipulate the queue directly since the Gs are
// already all linked the right way.
q.tail.set(gp)
}
// Put Gs back on the free list.
lock(&sched.gFree.lock)
sched.gFree.noStack.pushAll(q)
unlock(&sched.gFree.lock)
}
在GC Mark结束时，会释放stackpool内存块，并回收mcache.stackcache缓存。
func gcMarkTermination(nextTriggerRatio float64) {
...
// Free stack spans. This must be done between GC cycles.
systemstack(freeStackSpans)
// Ensure all mcaches are flushed. Each P will flush its own
// mcache before allocating, but idle Ps may not. Since this
// is necessary to sweep all spans, we need to ensure all
// mcaches are flushed before we start the next GC cycle.
systemstack(func() {
forEachP(func(_p_ *p) {
_p_.mcache.prepareForSweep()
})
})
...
}
func freeStackSpans() {
// Scan stack pools for empty stack spans.
for order := range stackpool {
lock(&stackpool[order].item.mu)
list := &stackpool[order].item.span
for s := list.first; s != nil; {
next := s.next
if s.allocCount == 0 {
list.remove(s)
s.manualFreeList = 0
osStackFree(s)
mheap_.freeManual(s, spanAllocStack)
}
s = next
}
unlock(&stackpool[order].item.mu)
}
// Free large stack spans.
lock(&stackLarge.lock)
for i := range stackLarge.free {
for s := stackLarge.free[i].first; s != nil; {
next := s.next
stackLarge.free[i].remove(s)
osStackFree(s)
mheap_.freeManual(s, spanAllocStack)
s = next
}
}
unlock(&stackLarge.lock)
}
func (c *mcache) prepareForSweep() {
sg := mheap_.sweepgen
if c.flushGen == sg {
return
} else if c.flushGen != sg-2 {
println("bad flushGen", c.flushGen, "in prepareForSweep; sweepgen", sg)
throw("bad flushGen")
}
c.releaseAll()
stackcache_clear(c)
atomic.Store(&c.flushGen, mheap_.sweepgen) // Synchronizes with gcStart
}
func stackcache_clear(c *mcache) {
if stackDebug >= 1 {
print("stackcache clear\n")
}
for order := uint8(0); order < _NumStackOrders; order++ {
lock(&stackpool[order].item.mu)
x := c.stackcache[order].list
for x.ptr() != nil {
y := x.ptr().next
stackpoolfree(x, order)
x = y
}
c.stackcache[order].list = 0
c.stackcache[order].size = 0
unlock(&stackpool[order].item.mu)
}
}
最后，对G的栈内存进行收缩：
func markroot(gcw *gcWork, i uint32) {
switch {
...
defaul :
...
scanstack(gp, gcw)
...
}
}
func scanstack(gp *g, gcw *gcWork) {
...
if isShrinkStackSafe(gp) {
// Shrink the stack if not much of it is being used.
shrinkstack(gp)
} else {
// Otherwise, shrink the stack at the next sync safe point.
gp.preemptShrink = true
}
...
}
References:
https://www.ardanlabs.com/blog/2017/05/language-mechanics-on-stacks-and-pointers.html
https://www.ardanlabs.com/blog/2017/05/language-mechanics-on-escape-analysis.html
https://www.jianshu.com/p/518466b4ee96
https://www.jianshu.com/p/63404461e520
https://zhuanlan.zhihu.com/p/28484133
https://zhuanlan.zhihu.com/p/237870981
https://draveness.me/golang/docs/part3-runtime/ch07-memory/golang-stack-management/
https://draveness.me/golang/docs/part3-runtime/ch07-memory/golang-stack-management
