go語言到底有什么好處

1. 部署簡單

創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于網(wǎng)站建設、成都網(wǎng)站制作、白水網(wǎng)絡推廣、小程序定制開發(fā)、白水網(wǎng)絡營銷、白水企業(yè)策劃、白水品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供白水建站搭建服務，24小時服務熱線：18982081108，官方網(wǎng)址：chinadenli.net

Go

編譯生成的是一個靜態(tài)可執(zhí)行文件，除了glibc外沒有其他外部依賴。這讓部署變得異常方便：目標機器上只需要一個基礎的系統(tǒng)和必要的管理、監(jiān)控工具，完全不需要操心應用所需的各種包、庫的依賴關系，大大減輕了維護的負擔。

2. 并發(fā)性好

Goroutine和channel使得編寫高并發(fā)的服務端軟件變得相當容易，很多情況下完全不需要考慮鎖機制以及由此帶來的各種問題。單個Go應用也能有效的利用多個CPU核，并行執(zhí)行的性能好。

3. 良好的語言設計

從學術的角度講Go語言其實非常平庸，不支持許多高級的語言特性;但從工程的角度講，Go的設計是非常優(yōu)秀的：規(guī)范足夠簡單靈活，有其他語言基礎的程序員都能迅速上手。更重要的是

Go 自帶完善的工具鏈，大大提高了團隊協(xié)作的一致性。

4. 執(zhí)行性能好

雖然不如 C 和 Java，但相比于其他編程語言，其執(zhí)行性能還是很好的，適合編寫一些瓶頸業(yè)務，內(nèi)存占用也非常省。

Go語言命令行利器cobra使用教程

cobra是一個提供簡單接口來創(chuàng)建強大的現(xiàn)代CLI界面的庫類似git git tools，cobra也是一個應用程序，它會生成你的應用程序的腳手架來快速開發(fā)基于cobra的應用程序

cobra提供：

cobra建立在命令、參數(shù)、標志的結(jié)構(gòu)之上

commands代表動作，args是事物，flags是動作的修飾符

最好的應用程序在使用時讀起來就像句子，因此，用戶直觀地知道如何與它們交互

模式如下：APPNAME VERB NOUN --ADJECTIVE. or APPNAME COMMAND ARG --FLAG（APPNAME 動詞 名詞 形容詞 或者 APPNAME 命令 參數(shù) 標志）

一些真實世界的好例子可以更好地說明這一點

kubectl 命令更能體現(xiàn)APPNAME 動詞 名詞 形容詞

如下的例子，server 是command，port是flag

這個命令中，我們告訴git 克隆url

命令是應用程序的中心點，應用程序支持的每一個交互都包含在一個命令中，命令可以有子命令，也可以運行操作

在上面的例子中，server是命令

更多關于cobra.Command

flag是一種修改命令行為的方式，cobra支持完全兼容POSIX標志，也支持go flag package，cobra可以定義到子命令上的標志，也可以僅對該命令可用的標志

在上面的命令中，port是標志

標志的功能由 pflag library 提供，pflag library是flag標準庫的一個分支，在添加POSIX兼容性的同時維護相同的接口。

使用cobra很簡單，首先，使用go get按照最新版本的庫，這個命令會安裝cobra可執(zhí)行程序以及庫和依賴項

下一步，引入cobra到應用程序中

雖然歡迎您提供自己的組織，但通常基于Cobra的應用程序?qū)⒆裱韵陆M織結(jié)構(gòu)：

在Cobra應用程序中，main.go文件通常非常簡單。它有一個目的：初始化Cobra。

使用cobra生成器

cobra提供了程序用來創(chuàng)建你的應用程序然后添加你想添加的命令，這是將cobra引入應用程序最簡單的方式

這兒 你可以發(fā)現(xiàn)關于cobra的更多信息

要手動實現(xiàn)cobra，需要創(chuàng)建一個main.go 和rootCmd文件，可以根據(jù)需要提供其他命令

Cobra不需要任何特殊的構(gòu)造器。只需創(chuàng)建命令。

理想情況下，您可以將其放在app/cmd/root.go中：

在init（）函數(shù)中定義標志和處理配置

例子如下，cmd/root.go:

創(chuàng)建main.go

使用root命令，您需要讓主函數(shù)執(zhí)行它。為清楚起見，Execute應該在根目錄下運行，盡管它可以在任何命令上調(diào)用。

在Cobra應用程序中，main.go文件通常非常簡單。它有一個目的：初始化Cobra。

可以定義其他命令，通常每個命令在cmd/目錄中都有自己的文件。

如果要創(chuàng)建版本命令，可以創(chuàng)建cmd/version.go并用以下內(nèi)容填充它：

如果希望將錯誤返回給命令的調(diào)用者，可以使用RunE。

然后可以在execute函數(shù)調(diào)用中捕獲錯誤。

標志提供修飾符來控制操作命令的操作方式。

由于標志是在不同的位置定義和使用的，因此我們需要在外部定義一個具有正確作用域的變量來分配要使用的標志。

有兩種不同的方法來分配標志。

標志可以是“持久”的，這意味著該標志將可用于分配給它的命令以及該命令下的每個命令。對于全局標志，在根上指定一個標志作為持久標志。

也可以在本地分配一個標志，該標志只應用于該特定命令。

默認情況下，Cobra只解析目標命令上的本地標志，而忽略父命令上的任何本地標志。通過啟用Command.TraverseChildren，Cobra將在執(zhí)行目標命令之前解析每個命令上的本地標志。

使用viper綁定標志

在本例中，持久標志author與viper綁定。注意：當用戶未提供--author標志時，變量author將不會設置為config中的值。

更多關于 viper的文檔

Flags默認是可選的，如果希望命令在未設置標志時報告錯誤，請根據(jù)需要進行標記：

持久性Flags

可以使用命令的Args字段指定位置參數(shù)的驗證。

內(nèi)置了以下驗證器：

在下面的示例中，我們定義了三個命令。兩個是頂級命令，一個（cmdTimes）是頂級命令之一的子命令。在這種情況下，根是不可執(zhí)行的，這意味著需要一個子命令。這是通過不為“rootCmd”提供“Run”來實現(xiàn)的。

我們只為一個命令定義了一個標志。

有關標志的更多文檔，請訪問

對于一個更完整的例子更大的應用程序，請檢查 Hugo 。

當您有子命令時，Cobra會自動將help命令添加到應用程序中。當用戶運行“應用程序幫助”時，將調(diào)用此函數(shù)。此外，help還支持所有其他命令作為輸入。例如，您有一個名為“create”的命令，沒有任何附加配置；調(diào)用“app help create”時，Cobra將起作用。每個命令都會自動添加“-help”標志。

以下輸出由Cobra自動生成。除了命令和標志定義之外，不需要任何東西。

幫助就像其他命令一樣。它周圍沒有特殊的邏輯或行為。事實上，你可以提供你想提供的。

您可以為默認命令提供自己的幫助命令或模板，以用于以下功能：

當用戶提供無效的標志或無效的命令時，Cobra通過向用戶顯示“用法”來響應。

你可以從上面的幫助中認識到這一點。這是因為默認幫助將用法作為其輸出的一部分嵌入。

您可以提供自己的使用函數(shù)或模板供Cobra使用。與幫助一樣，函數(shù)和模板也可以通過公共方法重寫：

如果在root命令上設置了version字段，Cobra會添加一個頂級的'--version'標志。運行帶有“-version”標志的應用程序?qū)⑹褂冒姹灸０鍖姹敬蛴〉綐藴瘦敵觥？梢允褂胏md.SetVersionTemplate（s string）函數(shù)自定義模板。

可以在命令的主運行函數(shù)之前或之后運行函數(shù)。PersistentPreRun和PreRun函數(shù)將在運行之前執(zhí)行。PersistentPostRun和PostRun將在運行后執(zhí)行。如果子函數(shù)不聲明自己的函數(shù)，則它們將繼承Persistent*Run函數(shù)。這些函數(shù)按以下順序運行：

輸出：

當發(fā)生“未知命令”錯誤時，Cobra將打印自動建議。這使得Cobra在發(fā)生拼寫錯誤時的行為類似于git命令。例如：

基于注冊的每個子命令和Levenshtein距離的實現(xiàn)，建議是自動的。匹配最小距離2（忽略大小寫）的每個已注冊命令都將顯示為建議。

如果需要在命令中禁用建議或調(diào)整字符串距離，請使用：

or

您還可以使用SuggestFor屬性顯式設置將為其建議給定命令的名稱。這允許對在字符串距離方面不接近的字符串提供建議，但在您的一組命令中是有意義的，并且對于某些您不需要別名的字符串。例子：

Cobra可以基于子命令、標志等生成文檔。請在 docs generation文檔 中閱讀更多關于它的信息。

Cobra可以為以下shell生成shell完成文件：bash、zsh、fish、PowerShell。如果您在命令中添加更多信息，這些補全功能將非常強大和靈活。在 Shell Completions 中閱讀更多關于它的信息。

Cobra is released under the Apache 2.0 license. See LICENSE.txt

json庫在golang中的使用

golang對json序列化和反序列化的操作實在是難受，所以說用習慣了高級語言特性，再轉(zhuǎn)到這些偏原生的寫法上就會很難受。

不多BB，開始記錄。

當寫個小demo或者做個小工具，沒有大規(guī)模使用場景，那使用哪個庫都是一樣的，因為性能的體現(xiàn)并不會很明顯。但是如果是在實際項目中使用，且伴隨著高并發(fā)，大容量等場景，我還是推薦使用 json-iterator 。

號稱最快的go json解析器。跟官方的寫法兼容，我目前基本都使用這個。

效率對比

ns 納秒 op 操作

倆種方式，一種直接反序列化成 結(jié)構(gòu)體數(shù)組，另一種反序列化為 slice，內(nèi)容為map[string]interface{}

結(jié)構(gòu)體數(shù)組

slice

徹底理解Golang Map

本文目錄如下，閱讀本文后，將一網(wǎng)打盡下面Golang Map相關面試題

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)。接下來，我們來詳細看下map的結(jié)構(gòu)

bmap 就是我們常說的“桶”，一個桶里面會最多裝 8 個 key，這些 key 之所以會落入同一個桶，是因為它們經(jīng)過哈希計算后，哈希結(jié)果是“一類”的，關于key的定位我們在map的查詢和插入中詳細說明。在桶內(nèi)，又會根據(jù) key 計算出來的 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)存空間。

當 map 的 key 和 value 都不是指針，并且 size 都小于 128 字節(jié)的情況下，會把 bmap 標記為不含指針，這樣可以避免 gc 時掃描整個 hmap。但是，我們看 bmap 其實有一個 overflow 的字段，是指針類型的，破壞了 bmap 不含指針的設想，這時會把 overflow 移動到 extra 字段來。

map是個指針，底層指向hmap，所以是個引用類型

golang 有三個常用的高級類型 slice 、map、channel, 它們都是 引用類型 ，當引用類型作為函數(shù)參數(shù)時，可能會修改原內(nèi)容數(shù)據(jù)。

golang 中沒有引用傳遞，只有值和指針傳遞。所以 map 作為函數(shù)實參傳遞時本質(zhì)上也是值傳遞，只不過因為 map 底層數(shù)據(jù)結(jié)構(gòu)是通過指針指向?qū)嶋H的元素存儲空間，在被調(diào)函數(shù)中修改 map，對調(diào)用者同樣可見，所以 map 作為函數(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 語言的設計者們有意為之，在每次 range 時的順序被隨機化，旨在提示開發(fā)者們，Go 底層實現(xiàn)并不保證 map 遍歷順序穩(wěn)定，請大家不要依賴 range 遍歷結(jié)果順序。

map 本身是無序的，且遍歷時順序還會被隨機化，如果想順序遍歷 map，需要對 map key 先排序，再按照 key 的順序遍歷 map。

map默認是并發(fā)不安全的，原因如下：

Go 官方在經(jīng)過了長時間的討論后，認為 Go map 更應適配典型使用場景（不需要從多個 goroutine 中進行安全訪問），而不是為了小部分情況（并發(fā)訪問），導致大部分程序付出加鎖代價（性能），決定了不支持。

場景: 2個協(xié)程同時讀和寫，以下程序會出現(xiàn)致命錯誤：fatal error: concurrent map writes

如果想實現(xiàn)map線程安全，有兩種方式：

方式一：使用讀寫鎖 map + sync.RWMutex

方式二：使用golang提供的 sync.Map

sync.map是用讀寫分離實現(xiàn)的，其思想是空間換時間。和map+RWLock的實現(xiàn)方式相比，它做了一些優(yōu)化：可以無鎖訪問read map，而且會優(yōu)先操作read map，倘若只操作read map就可以滿足要求(增刪改查遍歷)，那就不用去操作write map(它的讀寫都要加鎖)，所以在某些特定場景中它發(fā)生鎖競爭的頻率會遠遠小于map+RWLock的實現(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 是因為容量小于8時不需要生成多個桶，一個桶的容量就可以滿足

makemap函數(shù)會通過 fastrand 創(chuàng)建一個隨機的哈希種子，然后根據(jù)傳入的 hint 計算出需要的最小需要的桶的數(shù)量，最后再使用 makeBucketArray 創(chuàng)建用于保存桶的數(shù)組，這個方法其實就是根據(jù)傳入的 B 計算出的需要創(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。當要查詢的 key 不在 map 里，帶 comma 的用法會返回一個 bool 型變量提示 key 是否在 map 中；而不帶 comma 的語句則會返回一個 value 類型的零值。如果 value 是 int 型就會返回 0，如果 value 是 string 類型，就會返回空字符串。

map的查找通過生成匯編碼可以知道，根據(jù) key 的不同類型，編譯器會將查找函數(shù)用更具體的函數(shù)替換，以優(yōu)化效率：

函數(shù)首先會檢查 map 的標志位 flags。如果 flags 的寫標志位此時被置 1 了，說明有其他協(xié)程在執(zhí)行“寫”操作，進而導致程序 panic。這也說明了 map 對協(xié)程是不安全的。

key經(jīng)過哈希函數(shù)計算后，得到的哈希值如下（主流64位機下共 64 個 bit 位）：

m: 桶的個數(shù)

從buckets 通過 hash m 得到對應的bucket，如果bucket正在擴容，并且沒有擴容完成，則從oldbuckets得到對應的bucket

計算hash所在桶編號：

用上一步哈希值最后的 5 個 bit 位，也就是 01010 ，值為 10，也就是 10 號桶（范圍是0~31號桶）

計算hash所在的槽位:

用上一步哈希值哈希值的高8個bit 位，也就是 10010111 ，轉(zhuǎn)化為十進制，也就是151，在 10 號 bucket 中尋找** tophash 值（HOB hash）為 151* 的 槽位**，即為key所在位置，找到了 2 號槽位，這樣整個查找過程就結(jié)束了。

如果在 bucket 中沒找到，并且 overflow 不為空，還要繼續(xù)去 overflow bucket 中尋找，直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket。

通過上面找到了對應的槽位，這里我們再詳細分析下key/value值是如何獲取的：

bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 個 key 的地址就要在此基礎上跨過 i 個 key 的大小；而我們又知道，value 的地址是在所有 key 之后，因此第 i 個 value 的地址還需要加上所有 key 的偏移。

通過匯編語言可以看到，向 map 中插入或者修改 key，最終調(diào)用的是 mapassign 函數(shù)。

實際上插入或修改 key 的語法是一樣的，只不過前者操作的 key 在 map 中不存在，而后者操作的 key 存在 map 中。

mapassign 有一個系列的函數(shù)，根據(jù) key 類型的不同，編譯器會將其優(yōu)化為相應的“快速函數(shù)”。

我們只用研究最一般的賦值函數(shù) mapassign 。

map的賦值會附帶著map的擴容和遷移，map的擴容只是將底層數(shù)組擴大了一倍，并沒有進行數(shù)據(jù)的轉(zhuǎn)移，數(shù)據(jù)的轉(zhuǎn)移是在擴容后逐步進行的，在遷移的過程中每進行一次賦值（access或者delete）會至少做一次遷移工作。

1.判斷map是否為nil

每一次進行賦值/刪除操作時，只要oldbuckets != nil 則認為正在擴容，會做一次遷移工作，下面會詳細說下遷移過程

根據(jù)上面查找過程，查找key所在位置，如果找到則更新，沒找到則找空位插入即可

經(jīng)過前面迭代尋找動作，若沒有找到可插入的位置，意味著需要擴容進行插入，下面會詳細說下擴容過程

通過匯編語言可以看到，向 map 中刪除 key，最終調(diào)用的是 mapdelete 函數(shù)

刪除的邏輯相對比較簡單，大多函數(shù)在賦值操作中已經(jīng)用到過，核心還是找到 key 的具體位置。尋找過程都是類似的，在 bucket 中挨個 cell 尋找。找到對應位置后，對 key 或者 value 進行“清零”操作，將 count 值減 1，將對應位置的 tophash 值置成 Empty

再來說觸發(fā) map 擴容的時機：在向 map 插入新 key 的時候，會進行條件檢測，符合下面這 2 個條件，就會觸發(fā)擴容：

1、裝載因子超過閾值

源碼里定義的閾值是 6.5 (loadFactorNum/loadFactorDen)，是經(jīng)過測試后取出的一個比較合理的因子

我們知道，每個 bucket 有 8 個空位，在沒有溢出，且所有的桶都裝滿了的情況下，裝載因子算出來的結(jié)果是 8。因此當裝載因子超過 6.5 時，表明很多 bucket 都快要裝滿了，查找效率和插入效率都變低了。在這個時候進行擴容是有必要的。

對于條件 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 點識別不出來這種情況。表面現(xiàn)象就是計算裝載因子的分子比較小，即 map 里元素總數(shù)少，但是 bucket 數(shù)量多（真實分配的 bucket 數(shù)量多，包括大量的 overflow bucket）

不難想像造成這種情況的原因：不停地插入、刪除元素。先插入很多元素，導致創(chuàng)建了很多 bucket，但是裝載因子達不到第 1 點的臨界值，未觸發(fā)擴容來緩解這種情況。之后，刪除元素降低元素總數(shù)量，再插入很多元素，導致創(chuàng)建很多的 overflow bucket，但就是不會觸發(fā)第 1 點的規(guī)定，你能拿我怎么辦？overflow bucket 數(shù)量太多，導致 key 會很分散，查找插入效率低得嚇人，因此出臺第 2 點規(guī)定。這就像是一座空城，房子很多，但是住戶很少，都分散了，找起人來很困難

對于條件 2，其實元素沒那么多，但是 overflow bucket 數(shù)特別多，說明很多 bucket 都沒裝滿。解決辦法就是開辟一個新 bucket 空間，將老 bucket 中的元素移動到新 bucket，使得同一個 bucket 中的 key 排列地更緊密。這樣，原來，在 overflow bucket 中的 key 可以移動到 bucket 中來。結(jié)果是節(jié)省空間，提高 bucket 利用率，map 的查找和插入效率自然就會提升。

由于 map 擴容需要將原有的 key/value 重新搬遷到新的內(nèi)存地址，如果有大量的 key/value 需要搬遷，會非常影響性能。因此 Go map 的擴容采取了一種稱為“漸進式”的方式，原有的 key 并不會一次性搬遷完畢，每次最多只會搬遷 2 個 bucket。

上面說的 hashGrow() 函數(shù)實際上并沒有真正地“搬遷”，它只是分配好了新的 buckets，并將老的 buckets 掛到了 oldbuckets 字段上。真正搬遷 buckets 的動作在 growWork() 函數(shù)中，而調(diào)用 growWork() 函數(shù)的動作是在 mapassign 和 mapdelete 函數(shù)中。也就是插入或修改、刪除 key 的時候，都會嘗試進行搬遷 buckets 的工作。先檢查 oldbuckets 是否搬遷完畢，具體來說就是檢查 oldbuckets 是否為 nil。

如果未遷移完畢，賦值/刪除的時候，擴容完畢后（預分配內(nèi)存），不會馬上就進行遷移。而是采取 增量擴容 的方式，當有訪問到具體 bukcet 時，才會逐漸的進行遷移（將 oldbucket 遷移到 bucket）

nevacuate 標識的是當前的進度，如果都搬遷完，應該和2^B的長度是一樣的

在evacuate 方法實現(xiàn)是把這個位置對應的bucket，以及其沖突鏈上的數(shù)據(jù)都轉(zhuǎn)移到新的buckets上。

轉(zhuǎn)移的判斷直接通過tophash 就可以，判斷tophash中第一個hash值即可

遍歷的過程，就是按順序遍歷 bucket，同時按順序遍歷 bucket 中的 key。

map遍歷是無序的，如果想實現(xiàn)有序遍歷，可以先對key進行排序

為什么遍歷 map 是無序的？

如果發(fā)生過遷移，key 的位置發(fā)生了重大的變化，有些 key 飛上高枝，有些 key 則原地不動。這樣，遍歷 map 的結(jié)果就不可能按原來的順序了。

如果就一個寫死的 map，不會向 map 進行插入刪除的操作，按理說每次遍歷這樣的 map 都會返回一個固定順序的 key/value 序列吧。但是 Go 杜絕了這種做法，因為這樣會給新手程序員帶來誤解，以為這是一定會發(fā)生的事情，在某些情況下，可能會釀成大錯。

Go 做得更絕，當我們在遍歷 map 時，并不是固定地從 0 號 bucket 開始遍歷，每次都是從一個**隨機值序號的 bucket 開始遍歷，并且是從這個 bucket 的一個 隨機序號的 cell **開始遍歷。這樣，即使你是一個寫死的 map，僅僅只是遍歷它，也不太可能會返回一個固定序列的 key/value 對了。

為什么要使用 Go 語言，Go 語言的優(yōu)勢在哪里

部署簡單。Go編譯生成的是一個靜態(tài)可執(zhí)行文件，除了glibc外沒有其他外部依賴。這讓部署變得異常方便：目標機器上只需要一個基礎的系統(tǒng)和必要的管理、監(jiān)控工具，完全不需要操心應用所需的各種包、庫的依賴關系，大大減輕了維護的負擔。這和Python有著巨大的區(qū)別。由于歷史的原因，Python的部署工具生態(tài)相當混亂【比如setuptools,distutils,pip,

buildout的不同適用場合以及兼容性問題】。官方PyPI源又經(jīng)常出問題，需要搭建私有鏡像，而維護這個鏡像又要花費不少時間和精力。

并發(fā)性好。Goroutine和channel使得編寫高并發(fā)的服務端軟件變得相當容易，很多情況下完全不需要考慮鎖機制以及由此帶來的各種問題。單個Go應用也能有效的利用多個CPU核，并行執(zhí)行的性能好。這和Python也是天壤之比。多線程和多進程的服務端程序編寫起來并不簡單，而且由于全局鎖GIL的原因，多線程的Python程序并不能有效利用多核，只能用多進程的方式部署;如果用標準庫里的multiprocessing包又會對監(jiān)控和管理造成不少的挑戰(zhàn)【我們用的supervisor管理進程，對fork支持不好】。部署Python應用的時候通常是每個CPU核部署一個應用，這會造成不少資源的浪費，比如假設某個Python應用啟動后需要占用100MB內(nèi)存，而服務器有32個CPU核，那么留一個核給系統(tǒng)、運行31個應用副本就要浪費3GB的內(nèi)存資源。

良好的語言設計。從學術的角度講Go語言其實非常平庸，不支持許多高級的語言特性;但從工程的角度講，Go的設計是非常優(yōu)秀的：規(guī)范足夠簡單靈活，有其他語言基礎的程序員都能迅速上手。更重要的是Go自帶完善的工具鏈，大大提高了團隊協(xié)作的一致性。比如gofmt自動排版Go代碼，很大程度上杜絕了不同人寫的代碼排版風格不一致的問題。把編輯器配置成在編輯存檔的時候自動運行gofmt，這樣在編寫代碼的時候可以隨意擺放位置，存檔的時候自動變成正確排版的代碼。此外還有gofix,

govet等非常有用的工具。

執(zhí)行性能好。雖然不如C和Java，但通常比原生Python應用還是高一個數(shù)量級的，適合編寫一些瓶頸業(yè)務。內(nèi)存占用也非常省。

如何在golang 中調(diào)用c的靜態(tài)庫或者動態(tài)庫

Cgo 使得Go程序能夠調(diào)用C代碼. cgo讀入一個用特別的格式寫的Go語言源文件, 輸出Go和C程序, 使得C程序能打包到Go語言的程序包中.

舉例說明一下. 下面是一個Go語言包, 包含了兩個函數(shù) -- Random 和 Seed -- 是C語言庫中random和srandom函數(shù)的馬甲.

package rand

/*

#include stdlib.h

*/ import "C" func Random() int { return int(C.random()) } func Seed(i int) { C.srandom(C.uint(i)) }

我們來看一下這里都有什么內(nèi)容. 開始是一個包的導入語句.

rand包導入了"C"包, 但你會發(fā)現(xiàn)在Go的標準庫里沒有這個包. 那是因為C是一個"偽包", 一個為cgo引入的特殊的包名, 它是C命名空間的一個引用.

rand 包包含4個到C包的引用: 調(diào)用 C.random和C.srandom, 類型轉(zhuǎn)換 C.uint(i)還有引用語句.

Random函數(shù)調(diào)用libc中的random函數(shù), 然后回返結(jié)果. 在C中, random返回一個C類型的長整形值, cgo把它輪換為C.long. 這個值必需轉(zhuǎn)換成Go的類型, 才能在Go程序中使用. 使用一個常見的Go類型轉(zhuǎn)換:

func Random() int { return int(C.random()) }

這是一個等價的函數(shù), 使用了一個臨時變量來進行類型轉(zhuǎn)換:

func Random() int { var r C.long = C.random() return int(r) }

Seed函數(shù)則相反. 它接受一個Go語言的int類型, 轉(zhuǎn)換成C語言的unsigned int類型, 然后傳遞給C的srandom函數(shù).

func Seed(i int) { C.srandom(C.uint(i)) }

需要注意的是, cgo中的unsigned int類型寫為C.uint; cgo的文檔中有完整的類型列表.

這個例子中還有一個細節(jié)我們沒有說到, 那就是導入語句上面的注釋.

/*

#include stdlib.h

*/ import "C"

Cgo可以識別這個注釋, 并在編譯C語言程序的時候?qū)⑺斪饕粋€頭文件來處理. 在這個例子中, 它只是一個include語句, 然而其實它可以是使用有效的C語言代碼. 這個注釋必需緊靠在import "C"這個語句的上面, 不能有空行, 就像是文檔注釋一樣.

Strings and things

與Go語言不同, C語言中沒有顯式的字符串類型. 字符串在C語言中是一個以0結(jié)尾的字符數(shù)組.

Go和C語言中的字符串轉(zhuǎn)換是通過C.CString, C.GoString,和C.GoStringN這些函數(shù)進行的. 這些轉(zhuǎn)換將得到字符串類型的一個副本.

下一個例子是實現(xiàn)一個Print函數(shù), 它使用C標準庫中的fputs函數(shù)把一個字符串寫到標準輸出上:

package print // #include stdio.h // #include stdlib.h import "C" import "unsafe" func Print(s string) { cs := C.CString(s) C.fputs(cs, (*C.FILE)(C.stdout)) C.free(unsafe.Pointer(cs)) }

在C程序中進行的內(nèi)存分配是不能被Go語言的內(nèi)存管理器感知的. 當你使用C.CString創(chuàng)建一個C字符串時(或者其它類型的C語言內(nèi)存分配), 你必需記得在使用完后用C.free來釋放它.

調(diào)用C.CString將返回一個指向字符數(shù)組開始處的指錯, 所以在函數(shù)退出前我們把它轉(zhuǎn)換成一個unsafe.Pointer(Go中與C的void 等價的東西), 使用C.free來釋放分配的內(nèi)存. 一個慣用法是在分配內(nèi)存后緊跟一個defer(特別是當這段代碼比較復雜的時候), 這樣我們就有了下面這個Print函數(shù):

func Print(s string) { cs := C.CString(s) defer C.free(unsafe.Pointer(cs)) C.fputs(cs, (*C.FILE)(C.stdout)) }

構(gòu)建 cgo 包

如果你使用goinstall, 構(gòu)建cgo包就比較容易了, 只要調(diào)用像平常一樣使用goinstall命令, 它就能自動識別這個特殊的import "C", 然后自動使用cgo來編譯這些文件.

如果你想使用Go的Makefiles來構(gòu)建, 那在CGOFILES變量中列出那些要用cgo處理的文件, 就像GOFILES變量包含一般的Go源文件一樣.

rand包的Makefile可以寫成下面這樣:

include $(GOROOT)/src/Make.inc

TARG=goblog/rand

CGOFILES=\ rand.go\ include $(GOROOT)/src/Make.pkg

然后輸入gomake開始構(gòu)建.

更多 cgo 的資源

cgo的文檔中包含了關于C偽包的更多詳細的說明, 以及構(gòu)建過程. Go代碼樹中的cgo的例子給出了更多更高級的用法.

一個簡單而又符合Go慣用法的基于cgo的包是Russ Cox寫的gosqlite. 而Go語言的網(wǎng)站上也列出了更多的的cgo包.

最后, 如果你對于cgo的內(nèi)部是怎么運作這個事情感到好奇的話, 去看看運行時包的cgocall.c文件的注釋吧.

文章題目：go語言高級用法,go語法基礎知識
文章起源：http://chinadenli.net/article13/dsgspgs.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、服務器托管、電子商務、外貿(mào)網(wǎng)站建設、網(wǎng)站導航、云服務器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)