由于go語言是一個(gè)強(qiáng)類型的語言,因此hashmap也是有類型的,具體體現(xiàn)在key和value都必須指定類型,比如聲明一個(gè)key為string,value也是string的map,
創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)麗水,10多年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18980820575
需要這樣做
大部分類型都能做key,某些類型是不能的,共同的特點(diǎn)是: 不能使用== 來比較,包括: slice, map, function
在迭代的過程中是可以對(duì)map進(jìn)行刪除和更新操作的,規(guī)則如下:
golang的map是hash結(jié)構(gòu)的,意味著平均訪問時(shí)間是O(1)的。同傳統(tǒng)的hashmap一樣,由一個(gè)個(gè)bucket組成:
那我們?cè)趺丛L問到對(duì)應(yīng)的bucket呢,我們需要得到對(duì)應(yīng)key的hash值
各個(gè)參數(shù)的意思:
目前采用的是這一行:
| 6.50 | 20.90 | 10.79 | 4.25 | 6.50 |
// 先聲明map
var m1 map[string]string
// 再使用make函數(shù)創(chuàng)建一個(gè)非nil的map,nil map不能賦值
m1 = make(map[string]string)
// 最后給已聲明的map賦值
m1["a"] = "aa"
m1["b"] = "bb"
// 直接創(chuàng)建
m2 := make(map[string]string)
// 然后賦值
m2["a"] = "aa"
m2["b"] = "bb"
// 初始化 + 賦值一體化
m3 := map[string]string{
"a": "aa",
"b": "bb",
}
望采納。。
// ==========================================
// 查找鍵值是否存在
if v, ok := m1["a"]; ok {
fmt.Println(v)
} else {
fmt.Println("Key Not Found")
}
// 遍歷map
for k, v := range m1 {
fmt.Println(k, v)
}
不知道你有沒有聽過這么一句:在使用 map 時(shí)盡量不要在 big map 中保存指針。好吧,你現(xiàn)在已經(jīng)聽過了:)為什么呢?原因在于 Go 語言的垃圾回收器會(huì)掃描標(biāo)記 map 中的所有元素,GC 開銷相當(dāng)大,直接GG。
這兩天在《Mastering Go》中看到 GC 這一章節(jié)里面對(duì)比 map 和 slice 在垃圾回收中的效率對(duì)比,書中只給出結(jié)論沒有說明理由,這我是不能忍的,于是有了這篇學(xué)習(xí)筆記。扯那么多,Show Your Code
這是一個(gè)簡(jiǎn)單的測(cè)試程序,保存字符串的 map 和 保存整形的 map GC 的效率相差幾十倍,是不是有同學(xué)會(huì)說明明保存的是 string 哪有指針?這個(gè)要說到 Go 語言中 string 的底層實(shí)現(xiàn)了,源碼在 src/runtime/string.go里,可以看到 string 其實(shí)包含一個(gè)指向數(shù)據(jù)的指針和一個(gè)長(zhǎng)度字段。注意這里的是否包含指針,包括底層的實(shí)現(xiàn)。
Go 語言的 GC 會(huì)遞歸遍歷并標(biāo)記所有可觸達(dá)的對(duì)象,標(biāo)記完成之后將所有沒有引用的對(duì)象進(jìn)行清理。掃描到指針就會(huì)往下接著尋找,一直到結(jié)束。
Go 語言中 map 是基于 數(shù)組和鏈表 的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)的,通過 優(yōu)化的拉鏈法 解決哈希沖突,每個(gè) bucket 可以保存 8 對(duì)鍵值,在 8 個(gè)鍵值對(duì)數(shù)據(jù)后面有一個(gè) overflow 指針,因?yàn)橥爸凶疃嘀荒苎b 8 個(gè)鍵值對(duì),如果有多余的鍵值對(duì)落到了當(dāng)前桶,那么就需要再構(gòu)建一個(gè)桶(稱為溢出桶),通過 overflow 指針鏈接起來。
因?yàn)?overflow 指針的緣故,所以無論 map 保存的是什么,GC 的時(shí)候就會(huì)把所有的 bmap 掃描一遍,帶來巨大的 GC 開銷。官方 issues 就有關(guān)于這個(gè)問題的討論, runtime: Large maps cause significant GC pauses #9477
無腦機(jī)翻如下:
如果我們有一個(gè)map [k] v,其中k和v都不包含指針,并且我們想提高掃描性能,則可以執(zhí)行以下操作。
將“ allOverflow [] unsafe.Pointer”添加到 hmap 并將所有溢出存儲(chǔ)桶存儲(chǔ)在其中。 然后將 bmap 標(biāo)記為noScan。 這將使掃描非常快,因?yàn)槲覀儾粫?huì)掃描任何用戶數(shù)據(jù)。
實(shí)際上,它將有些復(fù)雜,因?yàn)槲覀冃枰獜腶llOverflow中刪除舊的溢出桶。 而且它還會(huì)增加 hmap 的大小,因此也可能需要重新整理數(shù)據(jù)。
最終官方在 hmap 中增加了 overflow 相關(guān)字段完成了上面的優(yōu)化,這是具體的 commit 地址。
下面看下具體是如何實(shí)現(xiàn)的,源碼基于 go1.15,src/cmd/compile/internal/gc/reflect.go 中
通過注釋可以看出,如果 map 中保存的鍵值都不包含指針(通過 Haspointers 判斷),就使用一個(gè) uintptr 類型代替 bucket 的指針用于溢出桶 overflow 字段,uintptr 類型在 GO 語言中就是個(gè)大小可以保存得下指針的整數(shù),不是指針,就相當(dāng)于實(shí)現(xiàn)了 將 bmap 標(biāo)記為 noScan, GC 的時(shí)候就不會(huì)遍歷完整個(gè) map 了。隨著不斷的學(xué)習(xí),愈發(fā)感慨 GO 語言中很多模塊設(shè)計(jì)得太精妙了。
差不多說清楚了,能力有限,有不對(duì)的地方歡迎留言討論,源碼位置還是問的群里大佬 _
sync.Map是1.9才推薦的并發(fā)安全的map,除了互斥量以外,還運(yùn)用了原子操作,所以在這之前,有必要了解下 Go語言——原子操作
go1.10\src\sync\map.go
entry分為三種情況:
從read中讀取key,如果key存在就tryStore。
注意這里開始需要加鎖,因?yàn)樾枰僮鱠irty。
條目在read中,首先取消標(biāo)記,然后將條目保存到dirty里。(因?yàn)闃?biāo)記的數(shù)據(jù)不在dirty里)
最后原子保存value到條目里面,這里注意read和dirty都有條目。
總結(jié)一下Store:
這里可以看到dirty保存了數(shù)據(jù)的修改,除非可以直接原子更新read,繼續(xù)保持read clean。
有了之前的經(jīng)驗(yàn),可以猜測(cè)下load流程:
與猜測(cè)的 區(qū)別 :
由于數(shù)據(jù)保存兩份,所以刪除考慮:
先看第二種情況。加鎖直接刪除dirty數(shù)據(jù)。思考下貌似沒什么問題,本身就是臟數(shù)據(jù)。
第一種和第三種情況唯一的區(qū)別就是條目是否被標(biāo)記。標(biāo)記代表刪除,所以直接返回。否則CAS操作置為nil。這里總感覺少點(diǎn)什么,因?yàn)闂l目其實(shí)還是存在的,雖然指針nil。
看了一圈貌似沒找到標(biāo)記的邏輯,因?yàn)閯h除只是將他變成nil。
之前以為這個(gè)邏輯就是簡(jiǎn)單的將為標(biāo)記的條目拷貝給dirty,現(xiàn)在看來大有文章。
p == nil,說明條目已經(jīng)被delete了,CAS將他置為標(biāo)記刪除。然后這個(gè)條目就不會(huì)保存在dirty里面。
這里其實(shí)就跟miss邏輯串起來了,因?yàn)閙iss達(dá)到閾值之后,dirty會(huì)全量變成read,也就是說標(biāo)記刪除在這一步最終刪除。這個(gè)還是很巧妙的。
真正的刪除邏輯:
很繞。。。。
本文名稱:go語言映射不到map go語言反射
地址分享:http://aaarwkj.com/article8/hhjhip.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供服務(wù)器托管、網(wǎng)站改版、、品牌網(wǎng)站制作、網(wǎng)站收錄、網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)