go語言中的指針和c++的指針的區(qū)別？

Go語言里面的指針和C++指針一樣，都是指向某塊內(nèi)存的地址值，可以解引用，不同只是在于C++里可以直接對指針做算術(shù)運算而Go里面不行。

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站建設(shè)、成都做網(wǎng)站、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)四平,十余年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

go語言中指針的使用場景？

如果該函數(shù)會修改receiver，此時一定要用指針

如果receiver是 struct 并且包含互斥類型 sync.Mutex ，或者是類似的同步變量，receiver必須是指針，這樣可以避免對象拷貝

如果receiver是較大的 struct 或者 array ，使用指針則更加高效。多大才算大？假設(shè)struct內(nèi)所有成員都要作為函數(shù)變量傳進去，如果覺得這時數(shù)據(jù)太多，就是struct太大

如果receiver是 struct ， array 或者 slice ，并且其中某個element指向了某個可變量，則這個時候receiver選指針會使代碼的意圖更加明顯

如果receiver使較小的 struct 或者 array ，并且其變量都是些不變量、常量，例如 time.Time ，value receiver更加適合，因為value receiver可以減少需要回收的垃圾量。

Go語言使用 map 時盡量不要在 big map 中保存指針

不知道你有沒有聽過這么一句：在使用 map 時盡量不要在 big map 中保存指針。好吧，你現(xiàn)在已經(jīng)聽過了：）為什么呢？原因在于 Go 語言的垃圾回收器會掃描標記 map 中的所有元素，GC 開銷相當大，直接GG。

這兩天在《Mastering Go》中看到 GC 這一章節(jié)里面對比 map 和 slice 在垃圾回收中的效率對比，書中只給出結(jié)論沒有說明理由，這我是不能忍的，于是有了這篇學習筆記。扯那么多，Show Your Code

這是一個簡單的測試程序，保存字符串的 map 和 保存整形的 map GC 的效率相差幾十倍，是不是有同學會說明明保存的是 string 哪有指針？這個要說到 Go 語言中 string 的底層實現(xiàn)了，源碼在 src/runtime/string.go里，可以看到 string 其實包含一個指向數(shù)據(jù)的指針和一個長度字段。注意這里的是否包含指針，包括底層的實現(xiàn)。

Go 語言的 GC 會遞歸遍歷并標記所有可觸達的對象，標記完成之后將所有沒有引用的對象進行清理。掃描到指針就會往下接著尋找，一直到結(jié)束。

Go 語言中 map 是基于 數(shù)組和鏈表 的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)的，通過 優(yōu)化的拉鏈法 解決哈希沖突，每個 bucket 可以保存 8 對鍵值，在 8 個鍵值對數(shù)據(jù)后面有一個 overflow 指針，因為桶中最多只能裝 8 個鍵值對，如果有多余的鍵值對落到了當前桶，那么就需要再構(gòu)建一個桶（稱為溢出桶），通過 overflow 指針鏈接起來。

因為 overflow 指針的緣故，所以無論 map 保存的是什么，GC 的時候就會把所有的 bmap 掃描一遍，帶來巨大的 GC 開銷。官方 issues 就有關(guān)于這個問題的討論， runtime: Large maps cause significant GC pauses #9477

無腦機翻如下：

如果我們有一個map [k] v，其中k和v都不包含指針，并且我們想提高掃描性能，則可以執(zhí)行以下操作。

將“ allOverflow [] unsafe.Pointer”添加到 hmap 并將所有溢出存儲桶存儲在其中。 然后將 bmap 標記為noScan。 這將使掃描非?？?，因為我們不會掃描任何用戶數(shù)據(jù)。

實際上，它將有些復雜，因為我們需要從allOverflow中刪除舊的溢出桶。 而且它還會增加 hmap 的大小，因此也可能需要重新整理數(shù)據(jù)。

最終官方在 hmap 中增加了 overflow 相關(guān)字段完成了上面的優(yōu)化，這是具體的 commit 地址。

下面看下具體是如何實現(xiàn)的，源碼基于 go1.15，src/cmd/compile/internal/gc/reflect.go 中

通過注釋可以看出，如果 map 中保存的鍵值都不包含指針（通過 Haspointers 判斷），就使用一個 uintptr 類型代替 bucket 的指針用于溢出桶 overflow 字段，uintptr 類型在 GO 語言中就是個大小可以保存得下指針的整數(shù)，不是指針，就相當于實現(xiàn)了 將 bmap 標記為 noScan， GC 的時候就不會遍歷完整個 map 了。隨著不斷的學習，愈發(fā)感慨 GO 語言中很多模塊設(shè)計得太精妙了。

差不多說清楚了，能力有限，有不對的地方歡迎留言討論，源碼位置還是問的群里大佬 _

Go語言有什么優(yōu)勢？

GO語言的優(yōu)勢：可直接編譯成機器碼，不依賴其他庫，glibc的版本有一定要求，部署就是扔一個文件上去就完成了。靜態(tài)類型語言，但是有動態(tài)語言的感覺，靜態(tài)類型的語言就是可以在編譯的時候檢查出來隱藏的大多數(shù)問題，動態(tài)語言的感覺就是有很多的包可以使用，寫起來的效率很高。語言層面支持并發(fā)，這個就是Go最大的特色，天生的支持并發(fā)，我曾經(jīng)說過一句話，天生的基因和整容是有區(qū)別的，大家一樣美麗，但是你喜歡整容的還是天生基因的美麗呢？Go就是基因里面支持的并發(fā)，可以充分的利用多核，很容易的使用并發(fā)。內(nèi)置runtime，支持垃圾回收，這屬于動態(tài)語言的特性之一吧，雖然目前來說GC不算完美，但是足以應(yīng)付我們所能遇到的大多數(shù)情況，特別是Go1.1之后的GC。簡單易學，Go語言的作者都有C的基因，那么Go自然而然就有了C的基因，那么Go關(guān)鍵字是25個，但是表達能力很強大，幾乎支持大多數(shù)你在其他語言見過的特性：繼承、重載、對象等。豐富的標準庫，Go目前已經(jīng)內(nèi)置了大量的庫，特別是網(wǎng)絡(luò)庫非常強大，我最愛的也是這部分。內(nèi)置強大的工具，Go語言里面內(nèi)置了很多工具鏈，最好的應(yīng)該是gofmt工具，自動化格式化代碼，能夠讓團隊review變得如此的簡單，代碼格式一模一樣，想不一樣都很困難?？缙脚_編譯，如果你寫的Go代碼不包含cgo，那么就可以做到window系統(tǒng)編譯linux的應(yīng)用，如何做到的呢？Go引用了plan9的代碼，這就是不依賴系統(tǒng)的信息。Go語言這么多的優(yōu)勢，你還不想學嗎？我記得當時我看的是黑馬程序員的視頻，我對他們視頻的印象就是通俗易懂，就是好！

為什么go語言適合開發(fā)網(wǎng)游服務(wù)器端

前段時間在golang-China讀到這個貼：

個人覺得golang十分適合進行網(wǎng)游服務(wù)器端開發(fā)，寫下這篇文章總結(jié)一下。

從網(wǎng)游的角度看：

要成功的運營一款網(wǎng)游，很大程度上依賴于玩家自發(fā)形成的社區(qū)。只有玩家自發(fā)形成一個穩(wěn)定的生態(tài)系統(tǒng)，游戲才能持續(xù)下去，避免鬼城的出現(xiàn)。而這就需要多次大量導入用戶，在同時在線用戶量達到某個臨界點的時候，才有可能完成。因此，多人同時在線十分有必要。

再來看網(wǎng)游的常見玩法，除了排行榜這類統(tǒng)計和數(shù)據(jù)匯總的功能外，基本沒有需要大量CPU時間的應(yīng)用。以前的項目里，即時戰(zhàn)斗產(chǎn)生的各種傷害計算對CPU的消耗也不大。玩家要完成一次操作，需要通過客戶端-服務(wù)器端-客戶端這樣一個來回，為了獲得高響應(yīng)速度，滿足玩家體驗，服務(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ù)相當高。另外，地圖信息的廣播也會帶來比較頻繁的網(wǎng)絡(luò)通信。磁盤IO方面，主要是游戲數(shù)據(jù)的保存。采用不同的數(shù)據(jù)庫，會有比較大的區(qū)別。以前的項目里，就經(jīng)歷了從MySQL轉(zhuǎn)向MongoDB這種內(nèi)存數(shù)據(jù)庫的過程，磁盤IO不再是瓶頸。總體來說，還是用內(nèi)存做一級緩沖，避免大量小數(shù)據(jù)塊讀寫的方案。

針對網(wǎng)游的這些特點，golang的語言特性十分適合開發(fā)游戲服務(wù)器端。

首先，go語言提供goroutine機制作為原生的并發(fā)機制。每個goroutine所需的內(nèi)存很少，實際應(yīng)用中可以啟動大量的goroutine對并發(fā)連接進行響應(yīng)。goroutine與gevent中的greenlet很相像，遇到IO阻塞的時候，調(diào)度器就會自動切換到另一個goroutine執(zhí)行，保證CPU不會因為IO而發(fā)生等待。而goroutine與gevent相比，沒有了python底層的GIL限制，就不需要利用多進程來榨取多核機器的性能了。通過設(shè)置最大線程數(shù)，可以控制go所啟動的線程，每個線程執(zhí)行一個goroutine，讓CPU滿負載運行。

同時，go語言為goroutine提供了獨到的通信機制channel。channel發(fā)生讀寫的時候，也會掛起當前操作channel的goroutine，是一種同步阻塞通信。這樣既達到了通信的目的，又實現(xiàn)同步，用CSP模型的觀點看，并發(fā)模型就是通過一組進程和進程間的事件觸發(fā)解決任務(wù)的。雖然說，主流的編程語言之間，只要是圖靈完備的，他們就都能實現(xiàn)相同的功能。但go語言提供的這種協(xié)程間通信機制，十分優(yōu)雅地揭示了協(xié)程通信的本質(zhì)，避免了以往鎖的顯式使用帶給程序員的心理負擔，確是一大優(yōu)勢。進行網(wǎng)游開發(fā)的程序員，可以將游戲邏輯按照單線程阻塞式的寫，不需要額外考慮線程調(diào)度的問題，以及線程間數(shù)據(jù)依賴的問題。因為，線程間的channel通信，已經(jīng)表達了線程間的數(shù)據(jù)依賴關(guān)系了，而go的調(diào)度器會給予妥善的處理。

另外，go語言提供的gc機制，以及對指針的保護式使用，可以大大減輕程序員的開發(fā)壓力，提高開發(fā)效率。

展望未來，我期待go語言社區(qū)能夠提供更多的goroutine間的隔離機制。個人十分推崇erlang社區(qū)的脆崩哲學，推動應(yīng)用發(fā)生預期外行為時，盡早崩潰，再fork出新進程處理新的請求。對于協(xié)程機制，需要由程序員保證執(zhí)行的函數(shù)不會發(fā)生死循環(huán)，導致線程卡死。如果能夠定制goroutine所執(zhí)行函數(shù)的最大CPU執(zhí)行時間，及所能使用的最大內(nèi)存空間，對于提升系統(tǒng)的魯棒性，大有裨益。

GO 一文搞懂指針和地址值的區(qū)別

go語言中的指針和地址值，在使用上常常具有迷惑性，主要是其特殊的*、符號的使用，可能會讓你摸不透，本文希望能講清楚go語言的指針(pointer)和值(value)。

這里先簡單的對指針和地址值概念做一個定義：

這是因為go方法傳遞參數(shù)的方式導致的，go方法函數(shù)傳遞參數(shù)傳遞的是一個拷貝，看看下面的程序會輸出什么？

答案是8，而不是9，因為AddAge函數(shù)修改的是學生的一個備份，而不是原始的學生對象

如果你想正確的給學生年齡增加的話，函數(shù)傳遞的需要是這個值的指針，如下所示：

需要注意的是，這里我們的指針傳遞的仍然是一個拷貝，比如，如果你將s賦值給另外一個指針地址，不會影響原有的指針，這點可以自行實踐下。

那在使用go語言開發(fā)的時候，何時該用指針何時改用地址值呢？比如考慮以下場景：

簡單原則： 當你不確定該使用哪種的時候，優(yōu)先使用指針

如果考慮在數(shù)組、切片、map等復合對象中使用指針和值，比如：

很多開發(fā)者會認為b會更高效，但是被傳遞的都是一個切片的拷貝，切片本身就是一個引用，所以這里被傳遞的其實沒有什么區(qū)別。

對于指針和地址值的使用，大家需要牢記的一點就是go數(shù)據(jù)傳遞的不可變性，活學活用此特點，在無狀態(tài)函數(shù)中此特性非常有用。