| 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}) |
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
}
...省略
}
//是否需要觸發(fā)GC
func (t gcTrigger) test() bool {
if !memstats.enablegc || panicking != 0 || gcphase != _GCoff {
return false
}
switch t.kind {
case gcTriggerHeap:
//gc_trigger是觸發(fā)標記的堆大小。當heap_live≥gc_trigger時，標記階段將開始。
//這也是必須完成比例掃描的堆大小。
//這是在標記終止期間根據下一個循環(huán)的觸發(fā)器的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的觸發(fā)場景
這里問題是gc的關鍵,比如當前用了10M內存,隨著程序運行,使用內存不是一個固定的值,在當次GC標記結束后,會更新下一次觸發(fā)gc的heap大小(gc_trigger),下次GC進入之后會在上述的test()函數中會進行heap大小的比較,如果符合條件就真正進行GC
func gcSetTriggerRatio(nextTriggerRatio)
補充：go的垃圾回收機制（GC）
1.引用計數(reference counting):如Python
2.標記-清掃(mark sweep)：如golang
3.復制收集(copy and collection):目前許多商業(yè)虛擬機都采用這種垃圾回收算法
golang 的垃圾回收(GC)是基于標記清掃算法，這種算法需要進行 STW（stop the world)，這個過程就會導致程序是卡頓的，頻繁的 GC 會嚴重影響程序性能. golang 在此基礎上進行了改進，通過三色標記清掃法與寫屏障來減少 STW 的時間.
三色標記法的流程如下，它將對象通過白、灰、黑進行標記
1.所有對象最開始都是白色.
2.從 root 開始找到所有可達對象，標記為灰色，放入待處理隊列。
3.歷灰色對象隊列，將其引用對象標記為灰色放入待處理隊列，自身標記為黑色。
4.循環(huán)步驟3直到灰色隊列為空為止，此時所有引用對象都被標記為黑色，所有不可達的對象依然為白色，白色的就是需要進行回收的對象。
三色標記法相對于普通標記清掃，減少了 STW 時間. 這主要得益于標記過程是 “on-the-fly” 的，在標記過程中是不需要 STW 的，它與程序是并發(fā)執(zhí)行的，這就大大縮短了 STW 的時間.
當標記和程序是并發(fā)執(zhí)行的，這就會造成一個問題. 在標記過程中，有新的引用產生，可能會導致誤清掃. 清掃開始前，標記為黑色的對象引用了一個新申請的對象，它肯定是白色的，而黑色對象不會被再次掃描，那么這個白色對象無法被掃描變成灰色、黑色，它就會最終被清掃，而實際它不應該被清掃. 這就需要用到屏障技術，golang 采用了寫屏障，作用就是為了避免這類誤清掃問題. 寫屏障即在內存寫操作前，維護一個約束，從而確保清掃開始前，黑色的對象不能引用白色對象.
1> 當前內存分配達到一定比例則觸發(fā)
2> 2 分鐘沒有觸發(fā)過 GC 則觸發(fā) GC
3> 手動觸發(fā)，調用 runtime.GC()
以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。
