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] = 100100map[string]interface{}: data["key"] = "value""value"map[interface{}]interface{}: data["key"] = "value"keyvaluemap[string][]string: data["key"] = []string{"hello"}map[string]*int*int[]*int: data[0] = &iifunc(*int): data(&i)ifunc([]string): data([]{"hello"})[]string{"hello"}chan []string: data <- []string{"hello"}[]string{"hello"}
以此类推,不一一列举了
多级间接赋值会导致 Go 编译器出现不必要的逃逸,在一些情况下可能我们只需要修改一下数据结构就会使性能有大幅提升。这也是很多人不推荐在 Go 中使用指针的原因,因为它会增加一级访问路径,而 map, slice, interface{}等类型是不可避免要用到的,为了减少不必要的逃逸,只能拿指针开刀了。
一般情况下我们会这样认为:“值的拷贝是昂贵的,所以用一个指针来代替。”
但是,在很多情况下,直接的值拷贝要比使用指针廉价的多。你可能要问为什么。
减少程序中指针的使用的另一个好处是,如果可以证明它里面没有指针,垃圾回收器会直接越过这块内存。
减少指针的使用不仅可以降低垃圾回收的工作量,它会产生对 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.newstackruntime.copystackruntime.stackfree
copystack
runtime.shrinkstackruntime.copystack
四、栈的操作
1. 栈的初始化
runtime.stackpoolruntime.stackLarge
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.mspanmcachemachemcental
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. 栈的分配
runtime.malgruntime.stackalloc
runtime.stackpoolmcache.stackcacheruntime.stackLargeruntime.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.stacksplitruntime.morestack
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 不需要被抢占,意味着我们需要新的栈空间来支持函数调用和本地变量的初始化,运行时会先检查目标大小的栈是否会溢出:
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)
}
_Gcopystackruntime.copystackruntime.stackalloc
func copystack(gp *g, newsize uintptr) {
old := gp.stack
used := old.hi - gp.sched.sp
new := stackalloc(uint32(newsize))
...
}
新栈的初始化和数据的复制是一个比较简单的过程,不过这不是整个过程中最复杂的地方,我们还需要将指向源栈中内存指向新的栈,在这期间我们需要分别调整以下的指针:
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.adjustpointerruntime.adjustinforuntime.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)
}
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