從2013年起,經(jīng)朋友推薦開始用Golang編寫游戲登陸服務(wù)器, 配合C++做第三方平臺驗(yàn)證. 到編寫?yīng)毩⒐ぞ邔?dǎo)表工具GitHub - davyxu/tabtoy: 跨平臺的高性能便捷電子表格導(dǎo)出器. 以及網(wǎng)絡(luò)庫GitHub - davyxu/cellnet: 簡單,方便,高效的Go語言的游戲服務(wù)器底層. 最終使用這些工具及庫編寫整個游戲服務(wù)器框架, 我的感受是很不錯的
創(chuàng)新互聯(lián)公司IDC提供業(yè)務(wù):成都移動機(jī)房托管,成都服務(wù)器租用,成都移動機(jī)房托管,重慶服務(wù)器租用等四川省內(nèi)主機(jī)托管與主機(jī)租用業(yè)務(wù);數(shù)據(jù)中心含:雙線機(jī)房,BGP機(jī)房,電信機(jī)房,移動機(jī)房,聯(lián)通機(jī)房。
細(xì)節(jié)看來, 有如下的幾個點(diǎn):
語言, 庫
Golang語言特性和C很像, 簡單, 一張A4紙就能寫完所有特性. 你想想看, C++到了領(lǐng)悟階段, 也只用那幾個簡單特性, 剩下的都是一大堆解決各種內(nèi)存問題的技巧. 而Golang一開始就簡單, 何必浪費(fèi)生命去研究那一大堆的奇技淫巧呢?
Golang的坑只有2個:1. interface{}和nil配合使用, 2. for循環(huán)時, 將循環(huán)變量引入閉包(Golang, Lua, C#閉包變量捕獲差異) 完全不影響正常使用, 復(fù)合語言概念, 只是看官方后面怎么有效的避免
用Golang就忘記繼承那套東西, 用組合+接口
用Golang服務(wù)器如何保證解決游戲服務(wù)器存盤一致性問題? stop the world是肯定的, 但是Golang可以從語言層并發(fā)序列化玩家數(shù)據(jù), 再通過后臺存盤
channel是goroutine雖然是Golang的語言特性. 但是在編寫服務(wù)器時, 其實(shí)只有底層用的比較多.
Golang的第三方庫簡直多如牛毛, 好的也很多
不要說模板了, C#的也不好用, 官方在糾結(jié)也不要加, 使用中, 沒模板確實(shí)有點(diǎn)不方便. 用interface{}/反射做泛型對于Golang這種強(qiáng)類型語言來說,還是有點(diǎn)打臉
運(yùn)行期
Golang和C++比性能的話, 這是C++的優(yōu)勢, Golang因?yàn)闆]虛擬機(jī), 只有薄薄的一層調(diào)度層. 因此性能是非常高的, 用一點(diǎn)性能犧牲換開發(fā)效率, 妥妥的
1.6版后的GC優(yōu)化的已經(jīng)很好了, 如果你不是高性能,高并發(fā)Web應(yīng)用, 非要找出一堆的優(yōu)化技巧的話. 只用Golang寫點(diǎn)游戲服務(wù)器, 那點(diǎn)GC損耗可以忽略不計(jì)
和其他現(xiàn)代語言一樣, 崩潰捕捉是標(biāo)配功能, 我用Golang的服務(wù)器線上跑, 基本沒碰到過崩潰情況
熱更新: 官方已經(jīng)有plugin系統(tǒng)的提交, 跨平臺的. 估計(jì)很快就可以告別手動cgo做so熱更新
開發(fā), 調(diào)試, 部署, 優(yōu)化
LiteIDE是我首選的Golang的IDE, 雖然有童鞋說B格不高. 但這估計(jì)實(shí)在是找不到缺點(diǎn)說了, 別跟我說Visual Studio, 那是宇宙級的...
曾經(jīng)聽說有人不看好Golang, 我問為啥: 說這么新的語言, 不好招人,后面打聽到他是個策劃... 好吧
真實(shí)情況是這樣的: Golang對于有點(diǎn)編程基礎(chǔ)的新人來說, 1周左右可以開始貢獻(xiàn)代碼. 老司機(jī)2~3天.
開發(fā)效率還是不錯的, 一般大的游戲功能, 2*2人一周3~4個整完. 這換C++時代, 大概也就1~2個還寫不完. 對接服務(wù)器sdk的話, 大概1天接個10多個沒問題
Golang自帶性能調(diào)優(yōu)工具, 從內(nèi)存, CPU, 阻塞點(diǎn)等幾個方面直接出圖進(jìn)行分析, 非常直觀, 可以參考我博客幾年前的分析: 使用Golang進(jìn)行性能分析(Profiling)
Golang支持交叉編譯, 跨平臺部署, 什么概念? linux是吧? 不問你什么版本, 直接windows上編譯輸出一個elf, 甩到服務(wù)器上開跑.不超過1分鐘時間..
前段時間在golang-China讀到這個貼:
個人覺得golang十分適合進(jìn)行網(wǎng)游服務(wù)器端開發(fā),寫下這篇文章總結(jié)一下。
從網(wǎng)游的角度看:
要成功的運(yùn)營一款網(wǎng)游,很大程度上依賴于玩家自發(fā)形成的社區(qū)。只有玩家自發(fā)形成一個穩(wěn)定的生態(tài)系統(tǒng),游戲才能持續(xù)下去,避免鬼城的出現(xiàn)。而這就需要多次大量導(dǎo)入用戶,在同時在線用戶量達(dá)到某個臨界點(diǎn)的時候,才有可能完成。因此,多人同時在線十分有必要。
再來看網(wǎng)游的常見玩法,除了排行榜這類統(tǒng)計(jì)和數(shù)據(jù)匯總的功能外,基本沒有需要大量CPU時間的應(yīng)用。以前的項(xiàng)目里,即時戰(zhàn)斗產(chǎn)生的各種傷害計(jì)算對CPU的消耗也不大。玩家要完成一次操作,需要通過客戶端-服務(wù)器端-客戶端這樣一個來回,為了獲得高響應(yīng)速度,滿足玩家體驗(yàn),服務(wù)器端的處理也不能占用太多時間。所以,每次請求對應(yīng)的CPU占用是比較小的。
網(wǎng)游的IO主要分兩個方面,一個是網(wǎng)絡(luò)IO,一個是磁盤IO。網(wǎng)絡(luò)IO方面,可以分成美術(shù)資源的IO和游戲邏輯指令的IO,這里主要分析游戲邏輯的IO。游戲邏輯的IO跟CPU占用的情況相似,每次請求的字節(jié)數(shù)很小,但由于多人同時在線,因此并發(fā)數(shù)相當(dāng)高。另外,地圖信息的廣播也會帶來比較頻繁的網(wǎng)絡(luò)通信。磁盤IO方面,主要是游戲數(shù)據(jù)的保存。采用不同的數(shù)據(jù)庫,會有比較大的區(qū)別。以前的項(xiàng)目里,就經(jīng)歷了從MySQL轉(zhuǎn)向MongoDB這種內(nèi)存數(shù)據(jù)庫的過程,磁盤IO不再是瓶頸??傮w來說,還是用內(nèi)存做一級緩沖,避免大量小數(shù)據(jù)塊讀寫的方案。
針對網(wǎng)游的這些特點(diǎn),golang的語言特性十分適合開發(fā)游戲服務(wù)器端。
首先,go語言提供goroutine機(jī)制作為原生的并發(fā)機(jī)制。每個goroutine所需的內(nèi)存很少,實(shí)際應(yīng)用中可以啟動大量的goroutine對并發(fā)連接進(jìn)行響應(yīng)。goroutine與gevent中的greenlet很相像,遇到IO阻塞的時候,調(diào)度器就會自動切換到另一個goroutine執(zhí)行,保證CPU不會因?yàn)镮O而發(fā)生等待。而goroutine與gevent相比,沒有了python底層的GIL限制,就不需要利用多進(jìn)程來榨取多核機(jī)器的性能了。通過設(shè)置最大線程數(shù),可以控制go所啟動的線程,每個線程執(zhí)行一個goroutine,讓CPU滿負(fù)載運(yùn)行。
同時,go語言為goroutine提供了獨(dú)到的通信機(jī)制channel。channel發(fā)生讀寫的時候,也會掛起當(dāng)前操作channel的goroutine,是一種同步阻塞通信。這樣既達(dá)到了通信的目的,又實(shí)現(xiàn)同步,用CSP模型的觀點(diǎn)看,并發(fā)模型就是通過一組進(jìn)程和進(jìn)程間的事件觸發(fā)解決任務(wù)的。雖然說,主流的編程語言之間,只要是圖靈完備的,他們就都能實(shí)現(xiàn)相同的功能。但go語言提供的這種協(xié)程間通信機(jī)制,十分優(yōu)雅地揭示了協(xié)程通信的本質(zhì),避免了以往鎖的顯式使用帶給程序員的心理負(fù)擔(dān),確是一大優(yōu)勢。進(jìn)行網(wǎng)游開發(fā)的程序員,可以將游戲邏輯按照單線程阻塞式的寫,不需要額外考慮線程調(diào)度的問題,以及線程間數(shù)據(jù)依賴的問題。因?yàn)?,線程間的channel通信,已經(jīng)表達(dá)了線程間的數(shù)據(jù)依賴關(guān)系了,而go的調(diào)度器會給予妥善的處理。
另外,go語言提供的gc機(jī)制,以及對指針的保護(hù)式使用,可以大大減輕程序員的開發(fā)壓力,提高開發(fā)效率。
展望未來,我期待go語言社區(qū)能夠提供更多的goroutine間的隔離機(jī)制。個人十分推崇erlang社區(qū)的脆崩哲學(xué),推動應(yīng)用發(fā)生預(yù)期外行為時,盡早崩潰,再fork出新進(jìn)程處理新的請求。對于協(xié)程機(jī)制,需要由程序員保證執(zhí)行的函數(shù)不會發(fā)生死循環(huán),導(dǎo)致線程卡死。如果能夠定制goroutine所執(zhí)行函數(shù)的最大CPU執(zhí)行時間,及所能使用的最大內(nèi)存空間,對于提升系統(tǒng)的魯棒性,大有裨益。
本文目錄如下,閱讀本文后,將一網(wǎng)打盡下面Golang Map相關(guān)面試題
Go中的map是一個指針,占用8個字節(jié),指向hmap結(jié)構(gòu)體; 源碼 src/runtime/map.go 中可以看到map的底層結(jié)構(gòu)
每個map的底層結(jié)構(gòu)是hmap,hmap包含若干個結(jié)構(gòu)為bmap的bucket數(shù)組。每個bucket底層都采用鏈表結(jié)構(gòu)。接下來,我們來詳細(xì)看下map的結(jié)構(gòu)
bmap 就是我們常說的“桶”,一個桶里面會最多裝 8 個 key,這些 key 之所以會落入同一個桶,是因?yàn)樗鼈兘?jīng)過哈希計(jì)算后,哈希結(jié)果是“一類”的,關(guān)于key的定位我們在map的查詢和插入中詳細(xì)說明。在桶內(nèi),又會根據(jù) key 計(jì)算出來的 hash 值的高 8 位來決定 key 到底落入桶內(nèi)的哪個位置(一個桶內(nèi)最多有8個位置)。
bucket內(nèi)存數(shù)據(jù)結(jié)構(gòu)可視化如下:
注意到 key 和 value 是各自放在一起的,并不是 key/value/key/value/... 這樣的形式。源碼里說明這樣的好處是在某些情況下可以省略掉 padding字段,節(jié)省內(nèi)存空間。
當(dāng) map 的 key 和 value 都不是指針,并且 size 都小于 128 字節(jié)的情況下,會把 bmap 標(biāo)記為不含指針,這樣可以避免 gc 時掃描整個 hmap。但是,我們看 bmap 其實(shí)有一個 overflow 的字段,是指針類型的,破壞了 bmap 不含指針的設(shè)想,這時會把 overflow 移動到 extra 字段來。
map是個指針,底層指向hmap,所以是個引用類型
golang 有三個常用的高級類型 slice 、map、channel, 它們都是 引用類型 ,當(dāng)引用類型作為函數(shù)參數(shù)時,可能會修改原內(nèi)容數(shù)據(jù)。
golang 中沒有引用傳遞,只有值和指針傳遞。所以 map 作為函數(shù)實(shí)參傳遞時本質(zhì)上也是值傳遞,只不過因?yàn)?map 底層數(shù)據(jù)結(jié)構(gòu)是通過指針指向?qū)嶋H的元素存儲空間,在被調(diào)函數(shù)中修改 map,對調(diào)用者同樣可見,所以 map 作為函數(shù)實(shí)參傳遞時表現(xiàn)出了引用傳遞的效果。
因此,傳遞 map 時,如果想修改map的內(nèi)容而不是map本身,函數(shù)形參無需使用指針
map 底層數(shù)據(jù)結(jié)構(gòu)是通過指針指向?qū)嶋H的元素 存儲空間 ,這種情況下,對其中一個map的更改,會影響到其他map
map 在沒有被修改的情況下,使用 range 多次遍歷 map 時輸出的 key 和 value 的順序可能不同。這是 Go 語言的設(shè)計(jì)者們有意為之,在每次 range 時的順序被隨機(jī)化,旨在提示開發(fā)者們,Go 底層實(shí)現(xiàn)并不保證 map 遍歷順序穩(wěn)定,請大家不要依賴 range 遍歷結(jié)果順序。
map 本身是無序的,且遍歷時順序還會被隨機(jī)化,如果想順序遍歷 map,需要對 map key 先排序,再按照 key 的順序遍歷 map。
map默認(rèn)是并發(fā)不安全的,原因如下:
Go 官方在經(jīng)過了長時間的討論后,認(rèn)為 Go map 更應(yīng)適配典型使用場景(不需要從多個 goroutine 中進(jìn)行安全訪問),而不是為了小部分情況(并發(fā)訪問),導(dǎo)致大部分程序付出加鎖代價(性能),決定了不支持。
場景: 2個協(xié)程同時讀和寫,以下程序會出現(xiàn)致命錯誤:fatal error: concurrent map writes
如果想實(shí)現(xiàn)map線程安全,有兩種方式:
方式一:使用讀寫鎖 map + sync.RWMutex
方式二:使用golang提供的 sync.Map
sync.map是用讀寫分離實(shí)現(xiàn)的,其思想是空間換時間。和map+RWLock的實(shí)現(xiàn)方式相比,它做了一些優(yōu)化:可以無鎖訪問read map,而且會優(yōu)先操作read map,倘若只操作read map就可以滿足要求(增刪改查遍歷),那就不用去操作write map(它的讀寫都要加鎖),所以在某些特定場景中它發(fā)生鎖競爭的頻率會遠(yuǎn)遠(yuǎn)小于map+RWLock的實(shí)現(xiàn)方式。
golang中map是一個kv對集合。底層使用hash table,用鏈表來解決沖突 ,出現(xiàn)沖突時,不是每一個key都申請一個結(jié)構(gòu)通過鏈表串起來,而是以bmap為最小粒度掛載,一個bmap可以放8個kv。在哈希函數(shù)的選擇上,會在程序啟動時,檢測 cpu 是否支持 aes,如果支持,則使用 aes hash,否則使用 memhash。
map有3鐘初始化方式,一般通過make方式創(chuàng)建
map的創(chuàng)建通過生成匯編碼可以知道,make創(chuàng)建map時調(diào)用的底層函數(shù)是 runtime.makemap 。如果你的map初始容量小于等于8會發(fā)現(xiàn)走的是 runtime.fastrand 是因?yàn)槿萘啃∮?時不需要生成多個桶,一個桶的容量就可以滿足
makemap函數(shù)會通過 fastrand 創(chuàng)建一個隨機(jī)的哈希種子,然后根據(jù)傳入的 hint 計(jì)算出需要的最小需要的桶的數(shù)量,最后再使用 makeBucketArray 創(chuàng)建用于保存桶的數(shù)組,這個方法其實(shí)就是根據(jù)傳入的 B 計(jì)算出的需要創(chuàng)建的桶數(shù)量在內(nèi)存中分配一片連續(xù)的空間用于存儲數(shù)據(jù),在創(chuàng)建桶的過程中還會額外創(chuàng)建一些用于保存溢出數(shù)據(jù)的桶,數(shù)量是 2^(B-4) 個。初始化完成返回hmap指針。
找到一個 B,使得 map 的裝載因子在正常范圍內(nèi)
Go 語言中讀取 map 有兩種語法:帶 comma 和 不帶 comma。當(dāng)要查詢的 key 不在 map 里,帶 comma 的用法會返回一個 bool 型變量提示 key 是否在 map 中;而不帶 comma 的語句則會返回一個 value 類型的零值。如果 value 是 int 型就會返回 0,如果 value 是 string 類型,就會返回空字符串。
map的查找通過生成匯編碼可以知道,根據(jù) key 的不同類型,編譯器會將查找函數(shù)用更具體的函數(shù)替換,以優(yōu)化效率:
函數(shù)首先會檢查 map 的標(biāo)志位 flags。如果 flags 的寫標(biāo)志位此時被置 1 了,說明有其他協(xié)程在執(zhí)行“寫”操作,進(jìn)而導(dǎo)致程序 panic。這也說明了 map 對協(xié)程是不安全的。
key經(jīng)過哈希函數(shù)計(jì)算后,得到的哈希值如下(主流64位機(jī)下共 64 個 bit 位):
m: 桶的個數(shù)
從buckets 通過 hash m 得到對應(yīng)的bucket,如果bucket正在擴(kuò)容,并且沒有擴(kuò)容完成,則從oldbuckets得到對應(yīng)的bucket
計(jì)算hash所在桶編號:
用上一步哈希值最后的 5 個 bit 位,也就是 01010 ,值為 10,也就是 10 號桶(范圍是0~31號桶)
計(jì)算hash所在的槽位:
用上一步哈希值哈希值的高8個bit 位,也就是 10010111 ,轉(zhuǎn)化為十進(jìn)制,也就是151,在 10 號 bucket 中尋找** tophash 值(HOB hash)為 151* 的 槽位**,即為key所在位置,找到了 2 號槽位,這樣整個查找過程就結(jié)束了。
如果在 bucket 中沒找到,并且 overflow 不為空,還要繼續(xù)去 overflow bucket 中尋找,直到找到或是所有的 key 槽位都找遍了,包括所有的 overflow bucket。
通過上面找到了對應(yīng)的槽位,這里我們再詳細(xì)分析下key/value值是如何獲取的:
bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 個 key 的地址就要在此基礎(chǔ)上跨過 i 個 key 的大??;而我們又知道,value 的地址是在所有 key 之后,因此第 i 個 value 的地址還需要加上所有 key 的偏移。
通過匯編語言可以看到,向 map 中插入或者修改 key,最終調(diào)用的是 mapassign 函數(shù)。
實(shí)際上插入或修改 key 的語法是一樣的,只不過前者操作的 key 在 map 中不存在,而后者操作的 key 存在 map 中。
mapassign 有一個系列的函數(shù),根據(jù) key 類型的不同,編譯器會將其優(yōu)化為相應(yīng)的“快速函數(shù)”。
我們只用研究最一般的賦值函數(shù) mapassign 。
map的賦值會附帶著map的擴(kuò)容和遷移,map的擴(kuò)容只是將底層數(shù)組擴(kuò)大了一倍,并沒有進(jìn)行數(shù)據(jù)的轉(zhuǎn)移,數(shù)據(jù)的轉(zhuǎn)移是在擴(kuò)容后逐步進(jìn)行的,在遷移的過程中每進(jìn)行一次賦值(access或者delete)會至少做一次遷移工作。
1.判斷map是否為nil
每一次進(jìn)行賦值/刪除操作時,只要oldbuckets != nil 則認(rèn)為正在擴(kuò)容,會做一次遷移工作,下面會詳細(xì)說下遷移過程
根據(jù)上面查找過程,查找key所在位置,如果找到則更新,沒找到則找空位插入即可
經(jīng)過前面迭代尋找動作,若沒有找到可插入的位置,意味著需要擴(kuò)容進(jìn)行插入,下面會詳細(xì)說下擴(kuò)容過程
通過匯編語言可以看到,向 map 中刪除 key,最終調(diào)用的是 mapdelete 函數(shù)
刪除的邏輯相對比較簡單,大多函數(shù)在賦值操作中已經(jīng)用到過,核心還是找到 key 的具體位置。尋找過程都是類似的,在 bucket 中挨個 cell 尋找。找到對應(yīng)位置后,對 key 或者 value 進(jìn)行“清零”操作,將 count 值減 1,將對應(yīng)位置的 tophash 值置成 Empty
再來說觸發(fā) map 擴(kuò)容的時機(jī):在向 map 插入新 key 的時候,會進(jìn)行條件檢測,符合下面這 2 個條件,就會觸發(fā)擴(kuò)容:
1、裝載因子超過閾值
源碼里定義的閾值是 6.5 (loadFactorNum/loadFactorDen),是經(jīng)過測試后取出的一個比較合理的因子
我們知道,每個 bucket 有 8 個空位,在沒有溢出,且所有的桶都裝滿了的情況下,裝載因子算出來的結(jié)果是 8。因此當(dāng)裝載因子超過 6.5 時,表明很多 bucket 都快要裝滿了,查找效率和插入效率都變低了。在這個時候進(jìn)行擴(kuò)容是有必要的。
對于條件 1,元素太多,而 bucket 數(shù)量太少,很簡單:將 B 加 1,bucket 最大數(shù)量( 2^B )直接變成原來 bucket 數(shù)量的 2 倍。于是,就有新老 bucket 了。注意,這時候元素都在老 bucket 里,還沒遷移到新的 bucket 來。新 bucket 只是最大數(shù)量變?yōu)樵瓉碜畲髷?shù)量的 2 倍( 2^B * 2 ) 。
2、overflow 的 bucket 數(shù)量過多
在裝載因子比較小的情況下,這時候 map 的查找和插入效率也很低,而第 1 點(diǎn)識別不出來這種情況。表面現(xiàn)象就是計(jì)算裝載因子的分子比較小,即 map 里元素總數(shù)少,但是 bucket 數(shù)量多(真實(shí)分配的 bucket 數(shù)量多,包括大量的 overflow bucket)
不難想像造成這種情況的原因:不停地插入、刪除元素。先插入很多元素,導(dǎo)致創(chuàng)建了很多 bucket,但是裝載因子達(dá)不到第 1 點(diǎn)的臨界值,未觸發(fā)擴(kuò)容來緩解這種情況。之后,刪除元素降低元素總數(shù)量,再插入很多元素,導(dǎo)致創(chuàng)建很多的 overflow bucket,但就是不會觸發(fā)第 1 點(diǎn)的規(guī)定,你能拿我怎么辦?overflow bucket 數(shù)量太多,導(dǎo)致 key 會很分散,查找插入效率低得嚇人,因此出臺第 2 點(diǎn)規(guī)定。這就像是一座空城,房子很多,但是住戶很少,都分散了,找起人來很困難
對于條件 2,其實(shí)元素沒那么多,但是 overflow bucket 數(shù)特別多,說明很多 bucket 都沒裝滿。解決辦法就是開辟一個新 bucket 空間,將老 bucket 中的元素移動到新 bucket,使得同一個 bucket 中的 key 排列地更緊密。這樣,原來,在 overflow bucket 中的 key 可以移動到 bucket 中來。結(jié)果是節(jié)省空間,提高 bucket 利用率,map 的查找和插入效率自然就會提升。
由于 map 擴(kuò)容需要將原有的 key/value 重新搬遷到新的內(nèi)存地址,如果有大量的 key/value 需要搬遷,會非常影響性能。因此 Go map 的擴(kuò)容采取了一種稱為“漸進(jìn)式”的方式,原有的 key 并不會一次性搬遷完畢,每次最多只會搬遷 2 個 bucket。
上面說的 hashGrow() 函數(shù)實(shí)際上并沒有真正地“搬遷”,它只是分配好了新的 buckets,并將老的 buckets 掛到了 oldbuckets 字段上。真正搬遷 buckets 的動作在 growWork() 函數(shù)中,而調(diào)用 growWork() 函數(shù)的動作是在 mapassign 和 mapdelete 函數(shù)中。也就是插入或修改、刪除 key 的時候,都會嘗試進(jìn)行搬遷 buckets 的工作。先檢查 oldbuckets 是否搬遷完畢,具體來說就是檢查 oldbuckets 是否為 nil。
如果未遷移完畢,賦值/刪除的時候,擴(kuò)容完畢后(預(yù)分配內(nèi)存),不會馬上就進(jìn)行遷移。而是采取 增量擴(kuò)容 的方式,當(dāng)有訪問到具體 bukcet 時,才會逐漸的進(jìn)行遷移(將 oldbucket 遷移到 bucket)
nevacuate 標(biāo)識的是當(dāng)前的進(jìn)度,如果都搬遷完,應(yīng)該和2^B的長度是一樣的
在evacuate 方法實(shí)現(xiàn)是把這個位置對應(yīng)的bucket,以及其沖突鏈上的數(shù)據(jù)都轉(zhuǎn)移到新的buckets上。
轉(zhuǎn)移的判斷直接通過tophash 就可以,判斷tophash中第一個hash值即可
遍歷的過程,就是按順序遍歷 bucket,同時按順序遍歷 bucket 中的 key。
map遍歷是無序的,如果想實(shí)現(xiàn)有序遍歷,可以先對key進(jìn)行排序
為什么遍歷 map 是無序的?
如果發(fā)生過遷移,key 的位置發(fā)生了重大的變化,有些 key 飛上高枝,有些 key 則原地不動。這樣,遍歷 map 的結(jié)果就不可能按原來的順序了。
如果就一個寫死的 map,不會向 map 進(jìn)行插入刪除的操作,按理說每次遍歷這樣的 map 都會返回一個固定順序的 key/value 序列吧。但是 Go 杜絕了這種做法,因?yàn)檫@樣會給新手程序員帶來誤解,以為這是一定會發(fā)生的事情,在某些情況下,可能會釀成大錯。
Go 做得更絕,當(dāng)我們在遍歷 map 時,并不是固定地從 0 號 bucket 開始遍歷,每次都是從一個**隨機(jī)值序號的 bucket 開始遍歷,并且是從這個 bucket 的一個 隨機(jī)序號的 cell **開始遍歷。這樣,即使你是一個寫死的 map,僅僅只是遍歷它,也不太可能會返回一個固定序列的 key/value 對了。
很多朋友可能知道Go語言的優(yōu)勢在哪,卻不知道Go語言適合用于哪些地方。
1、 Go語言作為服務(wù)器編程語言,很適合處理日志、數(shù)據(jù)打包、虛擬機(jī)處理、文件系統(tǒng)、分布式系統(tǒng)、數(shù)據(jù)庫代理等;網(wǎng)絡(luò)編程方面。Go語言廣泛應(yīng)用于Web應(yīng)用、API應(yīng)用、下載應(yīng)用等;除此之外,Go語言還可用于內(nèi)存數(shù)據(jù)庫和云平臺領(lǐng)域,目前國外很多云平臺都是采用Go開發(fā)。
2、 其實(shí)Go語言主要用作服務(wù)器端開發(fā)。其定位是用來開發(fā)"大型軟件"的,適合于很多程序員一起開發(fā)大型軟件,并且開發(fā)周期長,支持云計(jì)算的網(wǎng)絡(luò)服務(wù)。Go語言能夠讓程序員快速開發(fā),并且在軟件不斷的增長過程中,它能讓程序員更容易地進(jìn)行維護(hù)和修改。它融合了傳統(tǒng)編譯型語言的高效性和腳本語言的易用性和富于表達(dá)性。
3、 Go語言成功案例。Nsq:Nsq是由Go語言開發(fā)的高性能、高可用消息隊(duì)列系統(tǒng),性能非常高,每天能處理數(shù)十億條的消息;
4、 Docker:基于lxc的一個虛擬打包工具,能夠?qū)崿F(xiàn)PAAS平臺的組建。
5、 Packer:用來生成不同平臺的鏡像文件,例如VM、vbox、AWS等,作者是vagrant的作者
6、 Skynet:分布式調(diào)度框架。
7、 Doozer:分布式同步工具,類似ZooKeeper。
8、 Heka:mazila開源的日志處理系統(tǒng)。
9、 Cbfs:couchbase開源的分布式文件系統(tǒng)。
10、 Tsuru:開源的PAAS平臺,和SAE實(shí)現(xiàn)的功能一模一樣。
11、 Groupcache:memcahe作者寫的用于Google下載系統(tǒng)的緩存系統(tǒng)。
12、 God:類似redis的緩存系統(tǒng),但是支持分布式和擴(kuò)展性。
13、 Gor:網(wǎng)絡(luò)流量抓包和重放工具。
以上的就是關(guān)于go語言能做什么的內(nèi)容介紹了。
本文題目:go語言地圖服務(wù)器 google地圖
文章出自:http://redsoil1982.com.cn/article12/hpdcdc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供移動網(wǎng)站建設(shè)、網(wǎng)站營銷、網(wǎng)站設(shè)計(jì)、搜索引擎優(yōu)化、品牌網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)