GO中的defer會在當前函數(shù)返回前執(zhí)行傳入的函數(shù)，常用于關閉文件描述符，關閉鏈接及解鎖等操作。
成都創(chuàng)新互聯(lián)公司自2013年起，是專業(yè)互聯(lián)網(wǎng)技術服務公司，擁有項目成都網(wǎng)站設計、成都做網(wǎng)站網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元南明做網(wǎng)站,已為上家服務,為南明各地企業(yè)和個人服務,聯(lián)系電話:028-86922220
Go語言中使用defer時會遇到兩個常見問題：
接下來我們來詳細處理這兩個問題。
官方有段對defer的解釋：
這里我們先來一道經(jīng)典的面試題
你覺得這個會打印什么？
輸出結果：
這里是遵循先入后出的原則，同時保留當前變量的值。
把這道題簡化一下：
輸出結果
上述代碼輸出似乎不符合預期，這個現(xiàn)象出現(xiàn)的原因是什么呢？經(jīng)過分析，我們發(fā)現(xiàn)調(diào)用defer關鍵字會立即拷貝函數(shù)中引用的外部參數(shù)，所以fmt.Println(i)的這個i是在調(diào)用defer的時候就已經(jīng)賦值了，所以會直接打印1。
想要解決這個問題也很簡單，只需要向defer關鍵字傳入匿名函數(shù)
這里把一些垃圾回收使用的字段忽略了。
中間代碼生成階段cmd/compile/internal/gc/ssa.go會處理程序中的defer，該函數(shù)會根據(jù)條件不同，使用三種機制來處理該關鍵字
開放編碼、堆分配和棧分配是defer關鍵字的三種方法，而Go1.14加入的開放編碼，使得關鍵字開銷可以忽略不計。
call方法會為所有函數(shù)和方法調(diào)用生成中間代碼，工作內(nèi)容：
defer關鍵字在運行時會調(diào)用deferproc，這個函數(shù)實現(xiàn)在src/runtime/panic.go里，接受兩個參數(shù)：參數(shù)的大小和閉包所在的地址。
編譯器不僅將defer關鍵字轉(zhuǎn)成deferproc函數(shù)，還會通過以下三種方式為所有調(diào)用defer的函數(shù)末尾插入deferreturn的函數(shù)調(diào)用
1、在cmd/compile/internal/gc/walk.go的walkstmt函數(shù)中，在遇到ODEFFER節(jié)點時會執(zhí)行Curfn.Func.SetHasDefer(true)，設置當前函數(shù)的hasdefer屬性
2、在ssa.go的buildssa會執(zhí)行s.hasdefer = fn.Func.HasDefer()更新hasdefer
3、在exit中會根據(jù)hasdefer在函數(shù)返回前插入deferreturn的函數(shù)調(diào)用
runtime.deferproc為defer創(chuàng)建了一個runtime._defer結構體、設置它的函數(shù)指針fn、程序計數(shù)器pc和棧指針sp并將相關參數(shù)拷貝到相鄰的內(nèi)存空間中
最后調(diào)用的return0是唯一一個不會觸發(fā)延遲調(diào)用的函數(shù)，可以避免deferreturn的遞歸調(diào)用。
newdefer的分配方式是從pool緩存池中獲?。?/p>
這三種方式取到的結構體_defer，都會被添加到鏈表的隊頭，這也是為什么defer按照后進先出的順序執(zhí)行。
deferreturn就是從鏈表的隊頭取出并調(diào)用jmpdefer傳入需要執(zhí)行的函數(shù)和參數(shù)。
該函數(shù)只有在所有延遲函數(shù)都執(zhí)行后才會返回。
如果我們能夠?qū)⒉糠纸Y構體分配到棧上就可以節(jié)約內(nèi)存分配帶來的額外開銷。
在call函數(shù)中有在棧上分配
在運行期間deferprocStack只需要設置一些未在編譯期間初始化的字段，就可以將棧上的_defer追加到函數(shù)的鏈表上。
除了分配的位置和堆的不同，其他的大致相同。
Go語言在1.14中通過開放編碼實現(xiàn)defer關鍵字，使用代碼內(nèi)聯(lián)優(yōu)化defer關鍵的額外開銷并引入函數(shù)數(shù)據(jù)funcdata管理panic的調(diào)用，該優(yōu)化可以將 defer 的調(diào)用開銷從 1.13 版本的 ~35ns 降低至 ~6ns 左右。
然而開放編碼作為一種優(yōu)化 defer 關鍵字的方法，它不是在所有的場景下都會開啟的，開放編碼只會在滿足以下的條件時啟用：
如果函數(shù)中defer關鍵字的數(shù)量多于8個或者defer處于循環(huán)中，那么就會禁用開放編碼優(yōu)化。
可以看到這里，判斷編譯參數(shù)不用-N，返回語句的數(shù)量和defer數(shù)量的乘積小于15，會啟用開放編碼優(yōu)化。
延遲比特deferBitsTemp和延遲記錄是使用開放編碼實現(xiàn)defer的兩個最重要的結構，一旦使用開放編碼，buildssa會在棧上初始化大小為8個比特的deferBits
延遲比特中的每一個比特位都表示該位對應的defer關鍵字是否需要被執(zhí)行。延遲比特的作用就是標記哪些defer關鍵字在函數(shù)中被執(zhí)行，這樣就能在函數(shù)返回時根據(jù)對應的deferBits確定要執(zhí)行的函數(shù)。
而deferBits的大小為8比特，所以該優(yōu)化的條件就是defer的數(shù)量小于8.
而執(zhí)行延遲調(diào)用的時候仍在deferreturn
這里做了特殊的優(yōu)化，在runOpenDeferFrame執(zhí)行開放編碼延遲函數(shù)
1、從結構體_defer讀取deferBits，執(zhí)行函數(shù)等信息
2、在循環(huán)中依次讀取執(zhí)行函數(shù)的地址和參數(shù)信息，并通過deferBits判斷是否要執(zhí)行
3、調(diào)用reflectcallSave執(zhí)行函數(shù)
1、新加入的defer放入隊頭，執(zhí)行defer時是從隊頭取函數(shù)調(diào)用，所以是后進先出
2、通過判斷defer關鍵字、return數(shù)量來判斷是否開啟開放編碼優(yōu)化
3、調(diào)用deferproc函數(shù)創(chuàng)建新的延遲調(diào)用函數(shù)時，會立即拷貝函數(shù)的參數(shù)，函數(shù)的參數(shù)不會等到真正執(zhí)行時計算
Hello，大家好，又見面了！上一遍我們將 channel 相關基礎以及使用場景。這一篇，還需要再次進階理解channel 阻塞問題。以下創(chuàng)建一個chan類型為int，cap 為3。
channel 內(nèi)部其實是一個環(huán)形buf數(shù)據(jù)結構 ，是一種滑動窗口機制，當make完后，就分配在 Heap 上。
上面，向 chan 發(fā)送一條“hello”數(shù)據(jù)：
如果 G1 發(fā)送數(shù)據(jù)超過指定cap時，會出現(xiàn)什么情況？
看下面實例：
以上會出現(xiàn)什么，chan 緩沖區(qū)允許大小為1，如果再往chan仍數(shù)據(jù)，滿了就會被阻塞，那么是如何實現(xiàn)阻塞的呢？當 chan 滿時，會進入 gopark，此時 G1 進入一個 waiting 狀態(tài)，然后會創(chuàng)建一個 sudog 對象，其實就sendq隊列，把 200放進去。等 buf 不滿的時候，再喚醒放入buf里面。
通過如下源碼，你會更加清晰：
上面，從 chan 獲取數(shù)據(jù)：
Go 語言核心思想：“Do not communicate by sharing memory; instead, share memory by communicating.” 你可以看看這本書名叫：Effective Go
如果接收者，接收一個空對象，也會發(fā)生什么情況？
代碼示例 ：
也會報錯如下：
上面，從 chan 取出數(shù)據(jù)，可是沒有數(shù)據(jù)了。此時，它會把 接收者 G2 阻塞掉，也是和G1發(fā)送者一樣，也會執(zhí)行 gopark 將狀態(tài)改為 waiting，不一樣的點就是。
正常情況下，接收者G2作為取出數(shù)據(jù)是去 buf 讀取數(shù)據(jù)的，但現(xiàn)在，buf 為空了，此時，接收者G2會將sudog導出來，因為現(xiàn)在G2已經(jīng)被阻塞了嘛，會把G2給G，然后將 t := -ch 中變量 t 是在棧上的地址，放進去 elem ，也就是說，只存它的地址指針在sudog里面。
最后， ch - 200 當G1往 chan 添加200這個數(shù)據(jù)，正常情況是將數(shù)據(jù)添加到buf里面，然后喚醒 G2 是吧，而現(xiàn)在是將 G1 的添加200數(shù)據(jù)直接干到剛才G2阻塞的t這里變量里面。
你會認為，這樣真的可以嗎？想一想，G2 本來就是已經(jīng)阻塞了，然后我們直接這么干肯定沒有什么毛病，而且效率提高了，不需要再次放入buf再取出，這個過程也是需要時間。不然，不得往chan添加數(shù)據(jù)需要加鎖、拷貝、解鎖一序列操作，那肯定就慢了，我想Go語言是為了高效及內(nèi)存使用率的考慮這樣設計的。（注意，一般都是在runtime里面完成，不然會出現(xiàn)象安全問題。）
總結 ：
chan 類型的特點：chan 如果為空，receiver 接收數(shù)據(jù)的時候就會阻塞等待，直到 chan 被關閉或者有新的數(shù)據(jù)到來。有這種個機制，就可以實現(xiàn) wait/notify 的設計模式。
相關面試題：
1. 部署簡單
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)存占用也非常省。
本文目錄如下，閱讀本文后，將一網(wǎng)打盡下面Golang Map相關面試題
Go中的map是一個指針，占用8個字節(jié)，指向hmap結構體; 源碼 src/runtime/map.go 中可以看到map的底層結構
每個map的底層結構是hmap，hmap包含若干個結構為bmap的bucket數(shù)組。每個bucket底層都采用鏈表結構。接下來，我們來詳細看下map的結構
bmap 就是我們常說的“桶”，一個桶里面會最多裝 8 個 key，這些 key 之所以會落入同一個桶，是因為它們經(jīng)過哈希計算后，哈希結果是“一類”的，關于key的定位我們在map的查詢和插入中詳細說明。在桶內(nèi)，又會根據(jù) key 計算出來的 hash 值的高 8 位來決定 key 到底落入桶內(nèi)的哪個位置（一個桶內(nèi)最多有8個位置)。
bucket內(nèi)存數(shù)據(jù)結構可視化如下：
注意到 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ù)結構是通過指針指向?qū)嶋H的元素存儲空間，在被調(diào)函數(shù)中修改 map，對調(diào)用者同樣可見，所以 map 作為函數(shù)實參傳遞時表現(xiàn)出了引用傳遞的效果。
因此，傳遞 map 時，如果想修改map的內(nèi)容而不是map本身，函數(shù)形參無需使用指針
map 底層數(shù)據(jù)結構是通過指針指向?qū)嶋H的元素 存儲空間 ，這種情況下，對其中一個map的更改，會影響到其他map
map 在沒有被修改的情況下，使用 range 多次遍歷 map 時輸出的 key 和 value 的順序可能不同。這是 Go 語言的設計者們有意為之，在每次 range 時的順序被隨機化，旨在提示開發(fā)者們，Go 底層實現(xiàn)并不保證 map 遍歷順序穩(wěn)定，請大家不要依賴 range 遍歷結果順序。
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都申請一個結構通過鏈表串起來，而是以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 號槽位，這樣整個查找過程就結束了。
如果在 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 個空位，在沒有溢出，且所有的桶都裝滿了的情況下，裝載因子算出來的結果是 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é)省空間，提高 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 的結果就不可能按原來的順序了。
如果就一個寫死的 map，不會向 map 進行插入刪除的操作，按理說每次遍歷這樣的 map 都會返回一個固定順序的 key/value 序列吧。但是 Go 杜絕了這種做法，因為這樣會給新手程序員帶來誤解，以為這是一定會發(fā)生的事情，在某些情況下，可能會釀成大錯。
Go 做得更絕，當我們在遍歷 map 時，并不是固定地從 0 號 bucket 開始遍歷，每次都是從一個**隨機值序號的 bucket 開始遍歷，并且是從這個 bucket 的一個 隨機序號的 cell **開始遍歷。這樣，即使你是一個寫死的 map，僅僅只是遍歷它，也不太可能會返回一個固定序列的 key/value 對了。
Go語言中沒有“類”的概念，也不支持“類”的繼承等面向?qū)ο蟮母拍睢o語言中通過結構體的內(nèi)嵌再配合接口比面向?qū)ο缶哂懈叩臄U展性和靈活性。
自定義類型
在Go語言中有一些基本的數(shù)據(jù)類型，如string、整型、浮點型、布爾等數(shù)據(jù)類型， Go語言中可以使用type關鍵字來定義自定義類型。
自定義類型是定義了一個全新的類型。我們可以基于內(nèi)置的基本類型定義，也可以通過struct定義。例如：
通過Type關鍵字的定義，MyInt就是一種新的類型，它具有int的特性。
類型別名
類型別名是Go1.9版本添加的新功能。
類型別名規(guī)定：TypeAlias只是Type的別名，本質(zhì)上TypeAlias與Type是同一個類型。就像一個孩子小時候有小名、乳名，上學后用學名，英語老師又會給他起英文名，但這些名字都指的是他本人。
type TypeAlias = Type
我們之前見過的rune和byte就是類型別名，他們的定義如下：
類型定義和類型別名的區(qū)別
類型別名與類型定義表面上看只有一個等號的差異，我們通過下面的這段代碼來理解它們之間的區(qū)別。
結果顯示a的類型是main.NewInt，表示main包下定義的NewInt類型。b的類型是int。MyInt類型只會在代碼中存在，編譯完成時并不會有MyInt類型。
Go語言中的基礎數(shù)據(jù)類型可以表示一些事物的基本屬性，但是當我們想表達一個事物的全部或部分屬性時，這時候再用單一的基本數(shù)據(jù)類型明顯就無法滿足需求了，Go語言提供了一種自定義數(shù)據(jù)類型，可以封裝多個基本數(shù)據(jù)類型，這種數(shù)據(jù)類型叫結構體，英文名稱struct。 也就是我們可以通過struct來定義自己的類型了。
Go語言中通過struct來實現(xiàn)面向?qū)ο蟆?/p>
結構體的定義
使用type和struct關鍵字來定義結構體，具體代碼格式如下：
其中：
舉個例子，我們定義一個Person（人）結構體，代碼如下：
同樣類型的字段也可以寫在一行，
這樣我們就擁有了一個person的自定義類型，它有name、city、age三個字段，分別表示姓名、城市和年齡。這樣我們使用這個person結構體就能夠很方便的在程序中表示和存儲人信息了。
語言內(nèi)置的基礎數(shù)據(jù)類型是用來描述一個值的，而結構體是用來描述一組值的。比如一個人有名字、年齡和居住城市等，本質(zhì)上是一種聚合型的數(shù)據(jù)類型
結構體實例化
只有當結構體實例化時，才會真正地分配內(nèi)存。也就是必須實例化后才能使用結構體的字段。
基本實例化
舉個例子：
我們通過.來訪問結構體的字段（成員變量）,例如p1.name和p1.age等。
匿名結構體
在定義一些臨時數(shù)據(jù)結構等場景下還可以使用匿名結構體。
創(chuàng)建指針類型結構體
我們還可以通過使用new關鍵字對結構體進行實例化，得到的是結構體的地址。 格式如下：
從打印的結果中我們可以看出p2是一個結構體指針。
需要注意的是在Go語言中支持對結構體指針直接使用.來訪問結構體的成員。
取結構體的地址實例化
使用對結構體進行取地址操作相當于對該結構體類型進行了一次new實例化操作。
p3.name = "七米"其實在底層是(*p3).name = "七米"，這是Go語言幫我們實現(xiàn)的語法糖。
結構體初始化
沒有初始化的結構體，其成員變量都是對應其類型的零值。
使用鍵值對初始化
使用鍵值對對結構體進行初始化時，鍵對應結構體的字段，值對應該字段的初始值。
也可以對結構體指針進行鍵值對初始化，例如：
當某些字段沒有初始值的時候，該字段可以不寫。此時，沒有指定初始值的字段的值就是該字段類型的零值。
使用值的列表初始化
初始化結構體的時候可以簡寫，也就是初始化的時候不寫鍵，直接寫值：
使用這種格式初始化時，需要注意：
結構體內(nèi)存布局
結構體占用一塊連續(xù)的內(nèi)存。
輸出：
【進階知識點】關于Go語言中的內(nèi)存對齊推薦閱讀:在 Go 中恰到好處的內(nèi)存對齊
面試題
請問下面代碼的執(zhí)行結果是什么？
構造函數(shù)
Go語言的結構體沒有構造函數(shù)，我們可以自己實現(xiàn)。 例如，下方的代碼就實現(xiàn)了一個person的構造函數(shù)。 因為struct是值類型，如果結構體比較復雜的話，值拷貝性能開銷會比較大，所以該構造函數(shù)返回的是結構體指針類型。
調(diào)用構造函數(shù)
方法和接收者
Go語言中的方法（Method）是一種作用于特定類型變量的函數(shù)。這種特定類型變量叫做接收者（Receiver）。接收者的概念就類似于其他語言中的this或者 self。
方法的定義格式如下：
其中，
舉個例子：
方法與函數(shù)的區(qū)別是，函數(shù)不屬于任何類型，方法屬于特定的類型。
指針類型的接收者
指針類型的接收者由一個結構體的指針組成，由于指針的特性，調(diào)用方法時修改接收者指針的任意成員變量，在方法結束后，修改都是有效的。這種方式就十分接近于其他語言中面向?qū)ο笾械膖his或者self。 例如我們?yōu)镻erson添加一個SetAge方法，來修改實例變量的年齡。
調(diào)用該方法：
值類型的接收者
當方法作用于值類型接收者時，Go語言會在代碼運行時將接收者的值復制一份。在值類型接收者的方法中可以獲取接收者的成員值，但修改操作只是針對副本，無法修改接收者變量本身。
什么時候應該使用指針類型接收者
任意類型添加方法
在Go語言中，接收者的類型可以是任何類型，不僅僅是結構體，任何類型都可以擁有方法。 舉個例子，我們基于內(nèi)置的int類型使用type關鍵字可以定義新的自定義類型，然后為我們的自定義類型添加方法。
注意事項： 非本地類型不能定義方法，也就是說我們不能給別的包的類型定義方法。
結構體的匿名字段
匿名字段默認采用類型名作為字段名，結構體要求字段名稱必須唯一，因此一個結構體中同種類型的匿名字段只能有一個。
嵌套結構體
一個結構體中可以嵌套包含另一個結構體或結構體指針。
嵌套匿名結構體
當訪問結構體成員時會先在結構體中查找該字段，找不到再去匿名結構體中查找。
嵌套結構體的字段名沖突
嵌套結構體內(nèi)部可能存在相同的字段名。這個時候為了避免歧義需要指定具體的內(nèi)嵌結構體的字段。
結構體的“繼承”
Go語言中使用結構體也可以實現(xiàn)其他編程語言中面向?qū)ο蟮睦^承。
結構體字段的可見性
結構體中字段大寫開頭表示可公開訪問，小寫表示私有（僅在定義當前結構體的包中可訪問）。
結構體與JSON序列化
JSON(JavaScript Object Notation) 是一種輕量級的數(shù)據(jù)交換格式。易于人閱讀和編寫。同時也易于機器解析和生成。JSON鍵值對是用來保存JS對象的一種方式，鍵/值對組合中的鍵名寫在前面并用雙引號""包裹，使用冒號:分隔，然后緊接著值；多個鍵值之間使用英文,分隔。
結構體標簽（Tag）
Tag是結構體的元信息，可以在運行的時候通過反射的機制讀取出來。 Tag在結構體字段的后方定義，由一對反引號包裹起來，具體的格式如下：
`key1:"value1" key2:"value2"`
結構體標簽由一個或多個鍵值對組成。鍵與值使用冒號分隔，值用雙引號括起來。鍵值對之間使用一個空格分隔。 注意事項： 為結構體編寫Tag時，必須嚴格遵守鍵值對的規(guī)則。結構體標簽的解析代碼的容錯能力很差，一旦格式寫錯，編譯和運行時都不會提示任何錯誤，通過反射也無法正確取值。例如不要在key和value之間添加空格。
例如我們?yōu)镾tudent結構體的每個字段定義json序列化時使用的Tag：
沒有語言是垃圾，語言是工具，關鍵在于使用者。
1：go與c語言相比，go有垃圾回收，不會造成內(nèi)存泄露問題，go的語法簡潔優(yōu)美，同樣的c++100行代碼go大概50行可以做到，go的目標是能做C++能做的事，雖然目前可能不太實際
2：go的并行機制并不是一般的線程，通過channel和goroutine來實現(xiàn)，比線程還要輕量級很多，所以go適合高并發(fā)的服務器端
3：go是系統(tǒng)級別的語言，相當于c語言，java c#都是算比較高級的語言，這個不太好比，效率的話目前確實是要高一些，而且不需要外部依賴，所以go還是很強大的
重慶分公司
重慶分公司
