版本: go version go1.13 darwin/amd64
在go源码runtime目录中找到gcTrigger结构体,就能看出大致调用的位置
GC调用方式 | 所在位置 | 代码 |
---|---|---|
定时调用 | runtime/proc.go:forcegchelper() | gcStart(gcTrigger{kind: gcTriggerTime, now: nanotime()}) |
分配内存时调用 | runtime/malloc.go:mallocgc() | gcTrigger{kind: gcTriggerHeap} |
手动调用 | runtime/mgc.go:GC() | gcStart(gcTrigger{kind: gcTriggerCycle, n: n + 1}) |
调用入口有了,再进入gcStart
func gcStart(trigger gcTrigger) {
...省略
for trigger.test() && sweepone() != ^uintptr(0) {
sweep.nbgsweep++
}
// Perform GC initialization and the sweep termination
// transition.
semacquire(&work.startSema)
// Re-check transition condition under transition lock.
这里做了双重锁,来判断是否符合GC条件
if !trigger.test() {
semrelease(&work.startSema)
return
}
...省略
}
//是否需要触发GC
func (t gcTrigger) test() bool {
if !memstats.enablegc || panicking != 0 || gcphase != _GCoff {
return false
}
switch t.kind {
case gcTriggerHeap:
//gc_trigger是触发标记的堆大小。当heap_live≥gc_trigger时,标记阶段将开始。
//这也是必须完成比例扫描的堆大小。
//这是在标记终止期间根据下一个循环的触发器的triggerRatio计算的
return memstats.heap_live >= memstats.gc_trigger
case gcTriggerTime:
if gcpercent < 0 {
return false
}
lastgc := int64(atomic.Load64(&memstats.last_gc_nanotime))
// forcegcperiod = 默认是2分钟
return lastgc != 0 && t.now-lastgc > forcegcperiod
case gcTriggerCycle:
// t.n > work.cycles, but accounting for wraparound.
return int32(t.n-work.cycles) > 0
}
return true
}
后面的代码就是正常的垃圾回收流程了,这里暂且不表,这里只关心gc的触发场景
关于golang垃圾回收,内存分配时何时会重新进入GC?
这里问题是gc的关键,比如当前用了10M内存,随着程序运行,使用内存不是一个固定的值,在当次GC标记结束后,会更新下一次触发gc的heap大小(gc_trigger),下次GC进入之后会在上述的test()函数中会进行heap大小的比较,如果符合条件就真正进行GC
func gcSetTriggerRatio(nextTriggerRatio)