欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

golang gc的內(nèi)部優(yōu)化詳細介紹

 更新時間:2024年10月01日 16:30:48   作者:apocelipes  
Go編譯器在垃圾回收(GC)的掃描標記階段,對存儲無指針鍵值對的map進行了優(yōu)化,即在GC掃描時不深入掃描map內(nèi)部數(shù)據(jù),只檢查map本身是否需要回收,這一優(yōu)化顯著提升了GC掃描的速度,從而減少了GC對程序性能的影響

今天講一個常見的gc compiler(也就是官方版本的go編譯器和runtime)在垃圾回收的掃描標記階段做的優(yōu)化。

我對這個優(yōu)化的描述印象最深的是在bigcache的注釋里,大致內(nèi)容是如果map的鍵值都不包含指針,那么gc掃描的時候不管這個map多大都不會深入掃描map內(nèi)部存儲的數(shù)據(jù),只檢查map本身是否需要回收。

這么做的好處顯然是可以讓gc的掃描速度大大增加,從而減少gc對性能的損耗。

減少指針數(shù)量本身就是常見的優(yōu)化手段,但讓我感到好奇的是注釋里說的“跳過”。跳過的依據(jù)究竟是什么,以及只有map存在這種跳過嗎?

于是我進行了全面的搜索,結(jié)果除了復(fù)讀bigcache里那段話的,沒什么有用的發(fā)現(xiàn)。

于是這篇文章誕生了。

跳過掃描指的是什么

前置知識少不得。

簡單的說,gc在檢查對象是否存活的時候,除了對象本身,還要檢查對象的子對象是否引用了其他對象,具體來說:

  • 數(shù)組和slice的話指存儲在里面的每一個元素是否存活,這里被存儲的元素是數(shù)組/slice的子對象
  • map的子對象就是里面存的鍵和值了
  • struct的子對象是它的每一個字段

為了檢查這些子對象是否引用了其他對象(關(guān)系到這些被引用的對象是否能被回收),gc需要深入掃描這些子對象。子對象越多需要掃描的東西就越多。而且這個過程是遞歸的,因為子對象也會有子對象,想象一下嵌套的數(shù)組或者map。

跳過掃描自然就是指跳過這些子對象的掃描,只需要檢查對象本身即可的操作。

什么樣的對象是可以跳過掃描的

這也是我的第一個疑問。跳過或不跳過的依據(jù)是什么,又或者是什么東西在控制這一過程。

bigcache告訴我們存有不包含指針的鍵值對的map是可以跳過的,那么具體情況是怎么樣的呢?

找不到有用的資料,那只能看代碼了,代碼以Go 1.22.1為準。

首先應(yīng)該想到的應(yīng)該是從gc的代碼開始看,于是很快就有了收獲:

	// runtime/mgcmark.go

	// 負責gc掃描的函數(shù),還有個它的兄弟gcDrainN,代碼差不多就不放了

	func gcDrain(gcw *gcWork, flags gcDrainFlags) {

	...

	// 先標記所有root對象,檢查對象是否存活就是從這開始的

	if work.markrootNext < work.markrootJobs {

	for !(gp.preempt && (preemptible || sched.gcwaiting.Load() || pp.runSafePointFn != 0)) {

	markroot(gcw, job, flushBgCredit)

	// 檢查自己是否需要被中斷,需要的場合函數(shù)會直接跳到收尾工作然后返回

	}

	}

	


	// 從工作隊列里拿需要掃描的對象進行處理

	for !(gp.preempt && (preemptible || sched.gcwaiting.Load() || pp.runSafePointFn != 0)) {

	b := gcw.tryGetFast() // 從工作隊列拿對象

	scanobject(b, gcw)

	...

	}

	...

	}

流程不考慮中斷、數(shù)據(jù)統(tǒng)計和校驗的話還是很簡單的,就是先標記掃描的起點,然后從gcw這個工作隊列里拿東西出來處理,直到工作隊列里再也沒數(shù)據(jù)了為止。

markroot也很簡單,根據(jù)root對象的種類,它會調(diào)用scanblock或者markrootSpans。其中scanblock會調(diào)用greyobject來標記待處理的對象。因此稍微看看markrootSpans即可。

markrootSpans是用來處理那些存放設(shè)置了終結(jié)器的對象的內(nèi)存的:

// runtime/mgcmark.go
func markrootSpans(gcw *gcWork, shard int) {
...
for i := range specialsbits {
...
for j := uint(0); j < 8; j++ {
// 找到要處理的span(go內(nèi)存使用的單位,你就當是“一塊內(nèi)存空間”就行)
s := ha.spans[arenaPage+uint(i)*8+j]


...
lock(&s.speciallock)
for sp := s.specials; sp != nil; sp = sp.next {
if sp.kind != _KindSpecialFinalizer {
continue
}
// don't mark finalized object, but scan it so we
// retain everything it points to.
// spf是終結(jié)器本身
spf := (*specialfinalizer)(unsafe.Pointer(sp))
// A finalizer can be set for an inner byte of an object, find object beginning.
p := s.base() + uintptr(spf.special.offset)/s.elemsize*s.elemsize


// p是設(shè)置了終結(jié)器的對象
// 這里檢查這個對象占用的內(nèi)存上是否設(shè)置了跳過掃描的標記
// 設(shè)置了的話就不要繼續(xù)掃描對象自己的子對象了
if !s.spanclass.noscan() {
scanobject(p, gcw)
}


// 這個span本身就是root對象,所以剩下的直接用scanblock處理
scanblock(uintptr(unsafe.Pointer(&spf.fn)), goarch.PtrSize, &oneptrmask[0], gcw, nil)
}
unlock(&s.speciallock)
}
}
}

其實很簡單,依舊是找到所有的對象,然后進行處理。然而我們看到了有意思的東西:s.spanclass.noscan()。

看起來這和是否跳過掃描有關(guān)。

但我們先不深入這個方法,為什么?因為終結(jié)器是被特殊處理的,沒看完scanobjectgreyobject之前我們不能斷言這個方法是否控制著對對象的掃描。(其實注釋上我已經(jīng)告訴你就是這個東西控制的了,但如果你自己跟蹤代碼的話頭一次看到這段代碼的時候是不知道的)

所以我們接著看scanobject,這個函數(shù)是掃描對象的子對象的:

	// runtime/mgcmark.go

	func scanobject(b uintptr, gcw *gcWork) {

	// 先拿到還沒掃描過的內(nèi)存

	s := spanOfUnchecked(b)

	n := s.elemsize

	// n 表示mspan里有幾個對象,在被這個函數(shù)檢查的時候肯定不能是0

	if n == 0 {

	throw("scanobject n == 0")

	}

	if s.spanclass.noscan() {

	// 如果內(nèi)存設(shè)置了noscan標志,就報錯

	throw("scanobject of a noscan object")

	}

	


	var tp typePointers

	if n > maxObletBytes {

	// 大內(nèi)存分割成不同的塊放進工作隊列,這樣能被并行處理

	if b == s.base() {

	// 分割后入隊

	for oblet := b + maxObletBytes; oblet < s.base()+s.elemsize; oblet += maxObletBytes {

	if !gcw.putFast(oblet) {

	gcw.put(oblet)

	}

	}

	}

	


	// 獲取類型信息

	} else {

	// 這里不重要

	}

	


	var scanSize uintptr

	for {

	var addr uintptr

	// 獲取子對象

	// 整個循環(huán)的退出條件就是next不再返回子對象的時候(沒東西可繼續(xù)掃描了)

	if tp, addr = tp.nextFast(); addr == 0 {

	if tp, addr = tp.next(); addr == 0 {

	break

	}

	}

	


	// 拿到要處理的對象

	scanSize = addr - b + goarch.PtrSize

	obj := *(*uintptr)(unsafe.Pointer(addr))

	


	// 排除nil和指向當前對象自身的指針

	// 后者屬于可以被回收的循環(huán)引用,當前對象能不能回收不受這個指針影響

	// 因為如果當前對象不可訪問了,那么它的字段自然也是不可能被訪問到的,兩者均從root不可達

	// 而如果這個指針是可達的,那么當前對象的字段被引用,當前對象也是不需要回收的

	// 所以指向當前對象本身的指針字段不需要處理

	if obj != 0 && obj-b >= n {

	if obj, span, objIndex := findObject(obj, b, addr-b); obj != 0 {

	greyobject(obj, b, addr-b, span, gcw, objIndex)

	}

	}

	}

	...

	}

這個函數(shù)長歸長,條理還是清晰的:

  • 首先看看對象是否太大要把對象的內(nèi)存分割成小塊交給工作隊列里的其他協(xié)程并行處理
  • 接著掃描所有子對象,用greyobject標記這些對象

因為這個函數(shù)本身已經(jīng)是在掃描了,所以不太會有“跳過”的相關(guān)的邏輯,而且你也看到了把這個函數(shù)放在不需要掃描子對象的對象上調(diào)用時會觸發(fā)throw,throw會導(dǎo)致程序報錯并退出執(zhí)行。

所以秘密就在greyobject里了??纯创a:

	// runtime/mgcmark.go

	func greyobject(obj, base, off uintptr, span *mspan, gcw *gcWork, objIndex uintptr) {

	...

	if useCheckmark {

	if setCheckmark(obj, base, off, mbits) {

	// Already marked.

	return

	}

	} else {

	...

	// If marked we have nothing to do.

	if mbits.isMarked() {

	return

	}

	mbits.setMarked()

	


	...

	


	// 如果內(nèi)存被標記為不需要進一步掃描,則會跳過后續(xù)的流程(內(nèi)存會被放進gc掃描的工作隊列里等著被取出來掃描)

	if span.spanclass.noscan() {

	...

	return

	}

	}

	// 對象被放進工作隊列等待掃描

	}

這個函數(shù)會先檢查對象是否已經(jīng)被處理過,然后標記對象,接著檢查span上的noscan標志,設(shè)置了的話就返回調(diào)用,沒有設(shè)置說明需要被進一步掃描,于是被放進工作隊列,等著gcDrain或者它兄弟來處理。

現(xiàn)在我們可以得出結(jié)論了,會不會跳過掃描,全部由內(nèi)存上是否設(shè)置noscan標志來控制,設(shè)置了就可以跳過。

至于在這塊內(nèi)存上的是map還是slice還是struct,沒關(guān)系。

跳過掃描的具體流程

看了上面的代碼,我想信你一定是懵的,跳過具體發(fā)生的流程是什么樣的呢?

沒關(guān)系,我們看兩個例子就知道了。

第一個例子是一個頂層的全局的可跳過掃描的對象A,介于我們還沒說noscan會在什么情況下被設(shè)置,所以我們先忽略A的具體類型,只要知道它可以跳過掃描即可。

A的掃描流程是這樣的:

  • gc開始運行,先標記root對象
  • A就是root之一,所以它要么被scanblock處理要么被markrootSpan處理
  • 假設(shè)A設(shè)置了終結(jié)器,又因為A是可跳過掃描子對象的,因此markrootSpan會直接調(diào)用scanblock
  • scanblock會調(diào)用greyobject處理內(nèi)存里的對象
  • 因為A可跳過掃描,所以greyobject做完標記就返回了,A不會進入工作隊列
  • A的掃描結(jié)束,整個流程上不會有scanobject的調(diào)用

A的例子相對簡單,現(xiàn)在我們假設(shè)有個不是root對象的對象B,B本身不可跳過掃描,B有一個子對象C可以跳過掃描。我們來看看C的掃描流程:

  • 因為B并不是root對象,且不可跳過掃描,所以它作為某個root對象的子對象,現(xiàn)在肯定在gc工作隊列里
  • gcDrain從隊列里拿到了B,于是交給了scanobject處理
  • 我們假設(shè)B不是很大因此不會被分割(反正分割了也一樣)
  • scanobject把每個B的子對象都用greyobject處理,C也不例外
  • 因為C可跳過掃描,所以greyobject做完標記就返回了,C不會進入工作隊列
  • C的掃描結(jié)束,整個流程上不會有對C的scanobject的調(diào)用

這樣基本涵蓋了所有的情況,一些我沒單獨說的比如“可跳過對象E是不可跳過root對象D的子對象”這樣的情況,實際上和情況2沒什么區(qū)別。

現(xiàn)在對象的子對象掃描是這么跳過的我們也知道了,只剩一個疑問了:noscan標志是怎么設(shè)置的?

noscan標志是怎么設(shè)置的

在深入之前,我們先來簡單看下go的怎么分配內(nèi)存的。完整講解恐怕5篇長文也兜不住,所以我做些概念上的精簡。

在go里,mspan是內(nèi)存分配的基礎(chǔ)單位,一個mspan上可以分配多個大小類似可以被歸為一類的對象(比如13字節(jié)和14字節(jié)的對象都是一類,可以被分配到允許最大存儲16字節(jié)對象的mspan上)。這個“類型”就叫mpan的sizeclass。一個簡單的心智模型是把mspan當成一個能存大小相近的對象的列表。

為了加快內(nèi)存分配,go會給每個線程預(yù)分配一塊內(nèi)存,然后按sizeclass分成多份,每份對應(yīng)一個sizeclass的mspan。這個結(jié)構(gòu)叫mcache。

當然了,總有對象的大小會超過所有mcache的sizeclass規(guī)定的范圍,這個時候go就會像系統(tǒng)申請一大塊內(nèi)存,然后把內(nèi)存交給mspan。

存儲了span信息的比如sizeclass和noscan的結(jié)構(gòu)叫spanClass。這個結(jié)構(gòu)會作為字段存儲在mspan的控制結(jié)構(gòu)里。

知道了這些之后,我們就能看懂s.spanclass.noscan()了,它的意思就是檢查mspan的spanclass信息是否設(shè)置了不需要掃描子對象的標志。

而創(chuàng)建spanclass只能用makeSpanClass這個函數(shù):

	// runtime/mheap.go

	type spanClass uint8

	


	func makeSpanClass(sizeclass uint8, noscan bool) spanClass {

	return spanClass(sizeclass<<1) | spanClass(bool2int(noscan))

	}

現(xiàn)在問題簡單了,我們只要追蹤誰調(diào)用了這個函數(shù)就行,以及我們還知道額外的信息:這些調(diào)用者還需要從mcache或者系統(tǒng)申請內(nèi)存獲得mspan結(jié)構(gòu)。這樣一下范圍就收縮了。

按上面的思路,我們很快就找到了go分配內(nèi)存給對象的入口之一mallocgc

	// runtime/malloc.go

	func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {

	...

	// size是指類型的大小

	// typ是需要創(chuàng)建的對象的類型信息,如果只是分配內(nèi)存,typ要傳nil

	// typ是否是空的或者typ是否包含有指針

	noscan := typ == nil || !typ.Pointers()

	if 如果size足夠小可以從mspan上分配 {

	if size滿足要求可以用tinyallocator分配 {

	} else {

	// 計算sizeclass(size對應(yīng)到哪一類span)

	spc := makeSpanClass(sizeclass, noscan) // noscan是這里傳進去的

	span = c.alloc[spc] // 從mcache拿mspan

	v := nextFreeFast(span) // 從mspan真正拿到可用的內(nèi)存

	// 后面是把內(nèi)存內(nèi)容清零和維護gc信息等代碼

	}

	} else {

	// 大對象分配

	// mcache.allocLarge也調(diào)用makeSpanClass(0, noscan),然后用mheap.alloc根據(jù)span的信息從系統(tǒng)申請內(nèi)存

	span = c.allocLarge(size, noscan) // noscan是這里傳進去的

	// 后面是把內(nèi)存內(nèi)容清零和維護gc信息等代碼

	}

	}

即使sizeclass是一樣的,因為noscan的值不一樣,兩個spanClass的值也是不一樣的。對于可跳過掃描的大對象來說,會把為這個對象分配的內(nèi)存標記為noscan;對于可跳過的小對象來說,會直接把這個小對象放在mcache提前分配的不需要深入掃描的內(nèi)存區(qū)域上。

那么這個mallocgc又是誰調(diào)用的?答案太多了,因為new,make都會用到它。我們用slice和map做例子看看。

首先是slice。這個非常簡單,創(chuàng)建slice的入口是makeslice

	// runtime/slice.go

	func makeslice(et *_type, len, cap int) unsafe.Pointer {

	mem, overflow := math.MulUintptr(et.Size_, uintptr(cap))

	if overflow || mem > maxAlloc || len < 0 || len > cap {

	// NOTE: Produce a 'len out of range' error instead of a

	// 'cap out of range' error when someone does make([]T, bignumber).

	// 'cap out of range' is true too, but since the cap is only being

	// supplied implicitly, saying len is clearer.

	// See golang.org/issue/4085.

	mem, overflow := math.MulUintptr(et.Size_, uintptr(len))

	if overflow || mem > maxAlloc || len < 0 {

	panicmakeslicelen()

	}

	panicmakeslicecap()

	}

	


	return mallocgc(mem, et, true)

	}

slice中的元素的類型信息被傳給了mallocgc。如果slice的元素不包含指針,那么slice是可以跳過掃描的。

map比較特殊,跳過掃描的是它的bucket,而bucket外界是看不到的:

// runtime/map.go
	// 調(diào)用鏈:makemap -> makeBucketArray -> newarray -> mallocgc
	func makeBucketArray(t *maptype, b uint8, dirtyalloc unsafe.Pointer) (buckets unsafe.Pointer, nextOverflow *bmap) {
	base := bucketShift(b)
	nbuckets := base
	// For small b, overflow buckets are unlikely.
	// Avoid the overhead of the calculation.
	if b >= 4 {
	// Add on the estimated number of overflow buckets
	// required to insert the median number of elements
	// used with this value of b.
	nbuckets += bucketShift(b - 4)
	sz := t.Bucket.Size_ * nbuckets
	up := roundupsize(sz, !t.Bucket.Pointers())
	if up != sz {
	nbuckets = up / t.Bucket.Size_
	}
	}
	if dirtyalloc == nil {
	// t.Bucket.Pointers() 返回鍵值對中是否包含指針
	buckets = newarray(t.Bucket, int(nbuckets))
	} else {
	// dirtyalloc was previously generated by
	// the above newarray(t.Bucket, int(nbuckets))
	// but may not be empty.
	buckets = dirtyalloc
	size := t.Bucket.Size_ * nbuckets
	if t.Bucket.Pointers() {
	memclrHasPointers(buckets, size)
	} else {
	memclrNoHeapPointers(buckets, size)
	}
	}
	if base != nbuckets {
	// We preallocated some overflow buckets.
	// To keep the overhead of tracking these overflow buckets to a minimum,
	// we use the convention that if a preallocated overflow bucket's overflow
	// pointer is nil, then there are more available by bumping the pointer.
	// We need a safe non-nil pointer for the last overflow bucket; just use buckets.
	nextOverflow = (*bmap)(add(buckets, base*uintptr(t.BucketSize)))
	last := (*bmap)(add(buckets, (nbuckets-1)*uintptr(t.BucketSize)))
	last.setoverflow(t, (*bmap)(buckets))
	}
	return buckets, nextOverflow
	}
	func newarray(typ *_type, n int) unsafe.Pointer {
	if n == 1 {
	return mallocgc(typ.Size_, typ, true)
	}
	mem, overflow := math.MulUintptr(typ.Size_, uintptr(n))
	if overflow || mem > maxAlloc || n < 0 {
	panic(plainError("runtime: allocation size out of range"))
	}
	return mallocgc(mem, typ, true)
	}

可以看到要是鍵值對里都不包含指針的話,map就可以被跳過。

所以總結(jié)下,只要創(chuàng)建的對象不包含指針(例如數(shù)組/切片成員都是不包含指針的類型,map的鍵值對都不包含指針,結(jié)構(gòu)體所有字段不包含指針)或者只是單純分配塊內(nèi)存(makeslicecopy里分配一塊內(nèi)存然后再把數(shù)據(jù)copy進去的時候會判斷element里包不包含指針,不包含的時候會傳nil給mallocgc),noscan就會被設(shè)置。

現(xiàn)在所有的疑問都解決了:noscan是內(nèi)存分配時根據(jù)類型信息來設(shè)置的;能跳過掃描的不只是map,符合條件的類型不管是slice、map還是struct都可以。

優(yōu)化帶來的提升

說了這么多,這個優(yōu)化帶來的提升有多少呢?

看個例子:

var a int64 = 1000
	func generateIntSlice(n int64) []int64 {
	ret := make([]int64, 0, n)
	for i := int64(0); i < n; i++ {
	ret = append(ret, a)
	}
	return ret
	}
	func generatePtrSlice(n int64) []*int64 {
	ret := make([]*int64, 0, n)
	for i := int64(0); i < n; i++ {
	ret = append(ret, &a)
	}
	return ret
	}
	func BenchmarkGCScan1(b *testing.B) {
	defer debug.SetGCPercent(debug.SetGCPercent(-1)) // 測試期間禁止自動gc
	for i := 0; i < b.N; i++ {
	for j := 0; j < 20; j++ {
	generatePtrSlice(10000)
	}
	runtime.GC()
	}
	}
	func BenchmarkGCScan2(b *testing.B) {
	defer debug.SetGCPercent(debug.SetGCPercent(-1))
	for i := 0; i < b.N; i++ {
	for j := 0; j < 20; j++ {
	generateIntSlice(10000)
	}
	runtime.GC()
	}
	}

我們分別創(chuàng)建20個包含10000個int64或者*int64的slice(兩個類型在x64系統(tǒng)上都是8字節(jié)大?。缓笫謩佑|發(fā)一次GC。為了讓結(jié)果更準確,我們還在測試開始前禁用了自動觸發(fā)的gc,而且我們創(chuàng)建的slice的長度和slice里元素的大小都是一樣的,所以總體來說結(jié)果應(yīng)該比較接近真實的gc回收內(nèi)存時的性能。

這是結(jié)果:

	goos: windows

	goarch: amd64

	cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz

	│ old.txt │ new.txt │

	│ sec/op │ sec/op vs base │

	GCScan-8 379.0μ ± 2% 298.0μ ± 2% -21.51% (p=0.000 n=10)

	


	│ old.txt │ new.txt │

	│ B/op │ B/op vs base │

	GCScan-8 1.563Mi ± 0% 1.563Mi ± 0% ~ (p=0.438 n=10)

	


	│ old.txt │ new.txt │

	│ allocs/op │ allocs/op vs base │

	GCScan-8 20.00 ± 0% 20.00 ± 0% ~ (p=1.000 n=10) 1

	1 all samples are equal

內(nèi)存用量大家都一樣,但存指針的時候速度慢了五分之一。slice越大差距也會越大??梢娞^掃描帶來的提升還是很大的。

另外少用指針還有助于增加數(shù)據(jù)的局部性,不僅僅是惠及gc掃描。

如何利用這一優(yōu)化

最后我們看看如何利用這一優(yōu)化。

少用指針可以減輕gc壓力大家都知道,但有一些“不得不用”指針的時候。

以一個本地cache為例:

type Cache[K comparable, V any] struct {
	m map[K]*V
	}
	func (c *Cache[K, V]) Get(key K) *V {
	return c.m[key]
	}
	func (c *Cache[K, V]) Set(key Key, value *V) {
	c.m[key] = value
	}

值需要用指針是有兩個原因,一是map的元素不能取地址,如果我們想要cache里的數(shù)據(jù)可以自由使用的話那就不得不用臨時變量加復(fù)制,這樣如果我們想更新值的時候就會很麻煩;二是如果值很大的話復(fù)制帶來的開銷會很大,用cache就是想提升性能呢反過來下降了怎么行。

但這么做就會導(dǎo)致Cache.m里的每一個鍵值對要被掃描,如果鍵值對很多的話性能會十分感人。

這樣看起來是“不得不用指針”的場景。真的是這樣嗎?考慮到cache本身就是空間換時間的做法,我們不妨再多用點空間:

type index = int
	type Cache[K comparable, V any] struct {
	buf []V
	m map[K]index
	}
	func (c *Cache[K, V]) Get(key K) *V {
	idx, ok := c.m[key]
	if !ok {
	return nil
	}
	return &c.buf[idx] // 可以對slice里存的數(shù)據(jù)取地址
	}
	func (c *Cache[K, V]) Set(key Key, value V) {
	idx, ok := c.m[key]
	if !ok {
	// 新建
	c.m[key] = len(c.buf)
	c.buf = append(c.buf, value)
	return
	}
	// 覆蓋已添加的
	c.buf[idx] = value
	}

我們用一個slice來存所有的值,然后再把key映射到值在slice中的索引上。對于slice的元素,我們是可以取地址的,因此可以簡單拿到值的指針,對于值的更新也可以基于這個Get拿到的指針,時間復(fù)雜度不變,簡單又方便。

然后我們再來看,現(xiàn)在bufm都沒有指針了,只要KV不包含指針,那么不管我們的cache里存了多少東西對gc來說都只要看看外層的Cache對象是否存活就夠了。

但是這么做會有代價:

  • Get會稍微慢一點,因為不僅要做額外的檢查,還需要從兩個不同的數(shù)據(jù)結(jié)構(gòu)里拿數(shù)據(jù),對緩存不友好
  • 存數(shù)據(jù)進Cache的時候不可避免地需要一次復(fù)制
  • Get返回的指針沒有穩(wěn)定性,在底層的buf擴容后就會失效
  • 刪除元素會很慢,這怪我們用了slice而且需要維護map里的映射關(guān)系,解決方法倒是不少,比如你可以把待刪除元素和slice結(jié)尾的元素交換這樣slice里的其他元素不用移動map也只要遍歷一次,又比如你可以再多浪費點內(nèi)存用墓碑標志來模擬刪除或者干脆不提供刪除功能(不好做就干脆不做,這是非常golang的做法??)

順帶一提,前面說的bigcache就利用了類似的做法減輕了gc掃描壓力。

所以我建議先用benchmark和trace確定gc是性能瓶頸之后再進行上面這樣的優(yōu)化,否則性能優(yōu)化不了還會帶來很多額外的煩惱。

總結(jié)

現(xiàn)在我們知道了對于不包含指針的對象,gc會跳過對它內(nèi)部子對象的掃描,這個優(yōu)化不止于map。

接口雖然看起來不像指針,但其實它內(nèi)部也有指針,因此接口是要被深入掃描的。

另外還要強調(diào)一點,這個只是官方版本的go做的優(yōu)化,不保證其他的編譯器實現(xiàn)比如gccgo、tinygo會有類似的優(yōu)化。但少用指針減輕gc壓力是大多數(shù)語言的共識,這點不會錯。

最后的最后,還是老話,過早的優(yōu)化是萬惡之源,但用這句話給自己低性能的設(shè)計找借口更是錯上加錯,性能問題靠數(shù)據(jù)說話,多做benchmark少做白日夢。

到此這篇關(guān)于golang gc的內(nèi)部優(yōu)化詳細介紹的文章就介紹到這了,更多相關(guān)golang gc的內(nèi)部優(yōu)化 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • go語言制作的zip壓縮程序

    go語言制作的zip壓縮程序

    這篇文章主要介紹了go語言制作的zip壓縮程序,其主體思路是首先創(chuàng)建一個讀寫緩沖,然后用壓縮器包裝該緩沖,用Walk方法來將所有目錄下的文件寫入zip,有需要的小伙伴參考下。
    2015-03-03
  • 如何使用Go語言獲取當天、昨天、明天、某天0點時間戳以及格式化時間

    如何使用Go語言獲取當天、昨天、明天、某天0點時間戳以及格式化時間

    這篇文章主要給大家介紹了關(guān)于如何使用Go語言獲取當天、昨天、明天、某天0點時間戳以及格式化時間的相關(guān)資料,格式化時間戳是將時間戳轉(zhuǎn)換為特定的日期和時間格式,文中通過代碼示例介紹的非常詳細,需要的朋友可以參考下
    2023-10-10
  • golang實現(xiàn)大文件上傳功能全過程

    golang實現(xiàn)大文件上傳功能全過程

    Go語言可以用來實現(xiàn)大文件傳輸,下面這篇文章主要給大家介紹了關(guān)于golang實現(xiàn)大文件上傳功能的相關(guān)資料,文中通過實例代碼介紹的非常詳細,需要的朋友可以參考下
    2023-07-07
  • Go語言中重構(gòu)的技巧分享

    Go語言中重構(gòu)的技巧分享

    這篇文章主要來和大家分享一下Go語言中重構(gòu)的技巧,即如何盡量避免使用 else、break 和 continue,從而讓代碼更透明、更易讀,感興趣的小伙伴可以學習一下
    2023-10-10
  • go?map搬遷的實現(xiàn)

    go?map搬遷的實現(xiàn)

    本文主要介紹了go?map搬遷的實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2023-04-04
  • golang logrus日志框架實例詳解

    golang logrus日志框架實例詳解

    logrus是一個可插拔的、結(jié)構(gòu)化的日志框架,這篇文章主要介紹了golang logrus日志框架實例代碼,本文通過實例代碼給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2023-08-08
  • 使用go module導(dǎo)入本地包的方法教程詳解

    使用go module導(dǎo)入本地包的方法教程詳解

    go module 將是Go語言默認的依賴管理工具。到今天 Go1.14 版本推出之后 Go modules 功能已經(jīng)被正式推薦在生產(chǎn)環(huán)境下使用了。本文重點給大家介紹如何使用 go module 導(dǎo)入本地包,感興趣的朋友一起看看吧
    2020-03-03
  • GO中高效的將int轉(zhuǎn)換為string的方法與源碼

    GO中高效的將int轉(zhuǎn)換為string的方法與源碼

    本文將從逐步介紹幾種在?Go?中將?int?轉(zhuǎn)換為?string?的常見方法,并重點剖析這幾種方法在性能上的特點,另外,還會重點介紹?FormatInt?高效的算法實現(xiàn),需要的朋友可以參考下
    2024-01-01
  • go語言go?func(){select{}}()的用法

    go語言go?func(){select{}}()的用法

    本文主要介紹了go語言go?func(){select{}}()的用法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2024-02-02
  • Go語言數(shù)據(jù)結(jié)構(gòu)之單鏈表的實例詳解

    Go語言數(shù)據(jù)結(jié)構(gòu)之單鏈表的實例詳解

    鏈表由一系列結(jié)點(鏈表中每一個元素稱為結(jié)點)組成,結(jié)點可以在運行時動態(tài)生成。本文將通過五個例題帶大家深入了解Go語言中單鏈表的用法,感興趣的可以了解一下
    2022-08-08

最新評論