本文目錄一覽：
這可能是最全的golang的”==”比較規則了吧
大家經常用”==”來比較兩個變量是否相等。但是golang中的”==”有很多細節的地方，跟php是不一樣的。很多時候不能直接用”==”來比較，編譯器會直接報錯。
golang中基本類型的比較規則和複合類型的不一致，先介紹下golang的變量類型：
golang中的基本類型
比較的兩個變量類型必須相等。而且，golang沒有隱式類型轉換，比較的兩個變量必須類型完全一樣，類型別名也不行。如果要比較，先做類型轉換再比較。
複合類型是逐個字段，逐個元素比較的。需要注意的是， array 或者struct中每個元素必須要是可比較的，如果某個array的元素 or struct的成員不能比較(比如是後面介紹的slice，map等)，則此複合類型也不能比較。
逐個成員比較類型和值。每個對應成員的比較遵循基本類型變量的比較規則。
但是如果struct中有不可比較的成員類型時：
可以看到，struct中有slice這種不可比較的成員時，整個struct都不能做比較，即使沒有對slice那個成員賦值(slice默認值為nil)
slice和map的比較規則比較奇怪，我們先說普通的變量引用類型val和channel的比較規則。
引用類型變量存儲的是某個變量的內存地址。所以引用類型變量的比較，判斷的是這兩個引用類型存儲的是不是同一個變量。
上面看起來比較廢話，但是得理解引用類型的含義。不然對判斷規則還是不清楚。
slice類型不可比較，只能與零值nil做比較。
關於slice類型不可比較的原因，後面會專門寫文章做討論。
map類型和slice一樣，不能比較，只能與nil做比較。
接口類型的變量，包含該接口變量存儲的值和值的類型兩部分組成，分別稱為接口的動態類型和動態值。 只有動態類型和動態值都相同時，兩個接口變量才相同:
而且接口的動態類型必須要是可比較的，如果不能比較(比如slice，map)，則運行時會報panic。因為編譯器在編譯時無法獲取接口的動態類型，所以編譯能通過，但是運行時直接panic:
golang的func作為一等公民，也是一種類型，而且不可比較
上面說過，map和slice是不可比較類型，但是有沒有特殊的方法來對slice和map做比較呢，有
reflect.DeepEqual函數可以用來比較兩個任意類型的變量
對map類型做比較：
對slice類型做比較：
對struct類型做比較：
可以發現，只要變量的類型和值相同的話，reflect.DeepEqual比較的結果就為true
直接看用例：
結果為：
1， golang的類型再定義和類型別名
2，golang的slice和map為什麼不可以比較
1，
2，
3，
關於反射
在計算機科學領域，反射是指一類應用，它們能夠自描述和自控制。也就是說，這類應用通過採用某種機制來實現對自己行為的描述（self-representation）和監測（examination），並能根據自身行為的狀態和結果，調整或修改應用所描述行為的狀態和相關的語義。
每種語言的反射模型都不同，並且有些語言根本不支持反射。Golang語言實現了反射，反射機制就是在運行時動態的調用對象的方法和屬性，官方自帶的reflect包就是反射相關的，只要包含這個包就可以使用。
多插一句，Golang的gRPC也是通過反射實現的。
在講反射之前，先來看看Golang關於類型設計的一些原則
接下來要講的反射，就是建立在類型之上的，Golang的指定類型的變量的類型是靜態的（也就是指定int、string這些的變量，它的type是static type），在創建變量的時候就已經確定，反射主要與Golang的interface類型相關（它的type是concrete type），只有interface類型才有反射一說。
在Golang的實現中，每個interface變量都有一個對應pair，pair中記錄了實際變量的值和類型:
value是實際變量值，type是實際變量的類型。一個interface{}類型的變量包含了2個指針，一個指針指向值的類型【對應concrete type】，另外一個指針指向實際的值【對應value】。
例如，創建類型為*os.File的變量，然後將其賦給一個接口變量r：
接口變量r的pair中將記錄如下信息：(tty, *os.File)，這個pair在接口變量的連續賦值過程中是不變的，將接口變量r賦給另一個接口變量w:
接口變量w的pair與r的pair相同，都是:(tty, *os.File)，即使w是空接口類型，pair也是不變的。
interface及其pair的存在，是Golang中實現反射的前提，理解了pair，就更容易理解反射。反射就是用來檢測存儲在接口變量內部(值value；類型concrete type) pair對的一種機制。
既然反射就是用來檢測存儲在接口變量內部(值value；類型concrete type) pair對的一種機制。那麼在Golang的reflect反射包中有什麼樣的方式可以讓我們直接獲取到變量內部的信息呢？ 它提供了兩種類型（或者說兩個方法）讓我們可以很容易的訪問接口變量內容，分別是reflect.ValueOf() 和 reflect.TypeOf()，看看官方的解釋
reflect.TypeOf()是獲取pair中的type，reflect.ValueOf()獲取pair中的value，示例如下：
當執行reflect.ValueOf(interface)之後，就得到了一個類型為」relfect.Value」變量，可以通過它本身的Interface()方法獲得接口變量的真實內容，然後可以通過類型判斷進行轉換，轉換為原有真實類型。不過，我們可能是已知原有類型，也有可能是未知原有類型，因此，下面分兩種情況進行說明。
已知類型後轉換為其對應的類型的做法如下，直接通過Interface方法然後強制轉換，如下：
示例如下：
很多情況下，我們可能並不知道其具體類型，那麼這個時候，該如何做呢？需要我們進行遍歷探測其Filed來得知，示例如下:
通過運行結果可以得知獲取未知類型的interface的具體變量及其類型的步驟為：
通過運行結果可以得知獲取未知類型的interface的所屬方法（函數）的步驟為：
reflect.Value是通過reflect.ValueOf(X)獲得的，只有當X是指針的時候，才可以通過reflec.Value修改實際變量X的值，即：要修改反射類型的對象就一定要保證其值是「addressable」的。
示例如下：
這算是一個高級用法了，前面我們只說到對類型、變量的幾種反射的用法，包括如何獲取其值、其類型、如果重新設置新值。但是在工程應用中，另外一個常用並且屬於高級的用法，就是通過reflect來進行方法【函數】的調用。比如我們要做框架工程的時候，需要可以隨意擴展方法，或者說用戶可以自定義方法，那麼我們通過什麼手段來擴展讓用戶能夠自定義呢？關鍵點在於用戶的自定義方法是未可知的，因此我們可以通過reflect來搞定
示例如下：
Golang的反射很慢，這個和它的API設計有關。在 java 裏面，我們一般使用反射都是這樣來弄的。
這個取得的反射對象類型是 java.lang.reflect.Field。它是可以復用的。只要傳入不同的obj，就可以取得這個obj上對應的 field。
但是Golang的反射不是這樣設計的:
這裡取出來的 field 對象是 reflect.StructField 類型，但是它沒有辦法用來取得對應對象上的值。如果要取值，得用另外一套對object，而不是type的反射
這裡取出來的 fieldValue 類型是 reflect.Value，它是一個具體的值，而不是一個可復用的反射對象了，每次反射都需要malloc這個reflect.Value結構體，並且還涉及到GC。
Golang reflect慢主要有兩個原因
上述詳細說明了Golang的反射reflect的各種功能和用法，都附帶有相應的示例，相信能夠在工程應用中進行相應實踐，總結一下就是：
徹底理解Golang Map
本文目錄如下，閱讀本文後，將一網打盡下面Golang Map相關面試題
Go中的map是一個指針，佔用8個位元組，指向hmap結構體; 源碼 src/runtime/map.go 中可以看到map的底層結構
每個map的底層結構是hmap，hmap包含若干個結構為bmap的bucket數組。每個bucket底層都採用鏈表結構。接下來，我們來詳細看下map的結構
bmap 就是我們常說的「桶」，一個桶裏面會最多裝 8 個 key，這些 key 之所以會落入同一個桶，是因為它們經過哈希計算後，哈希結果是「一類」的，關於key的定位我們在map的查詢和插入中詳細說明。在桶內，又會根據 key 計算出來的 hash 值的高 8 位來決定 key 到底落入桶內的哪個位置（一個桶內最多有8個位置)。
bucket內存數據結構可視化如下：
注意到 key 和 value 是各自放在一起的，並不是 key/value/key/value/… 這樣的形式。源碼里說明這樣的好處是在某些情況下可以省略掉 padding字段，節省內存空間。
當 map 的 key 和 value 都不是指針，並且 size 都小於 128 位元組的情況下，會把 bmap 標記為不含指針，這樣可以避免 gc 時掃描整個 hmap。但是，我們看 bmap 其實有一個 overflow 的字段，是指針類型的，破壞了 bmap 不含指針的設想，這時會把 overflow 移動到 extra 字段來。
map是個指針，底層指向hmap，所以是個引用類型
golang 有三個常用的高級類型 slice 、map、channel, 它們都是 引用類型 ，當引用類型作為函數參數時，可能會修改原內容數據。
golang 中沒有引用傳遞，只有值和指針傳遞。所以 map 作為函數實參傳遞時本質上也是值傳遞，只不過因為 map 底層數據結構是通過指針指向實際的元素存儲空間，在被調函數中修改 map，對調用者同樣可見，所以 map 作為函數實參傳遞時表現出了引用傳遞的效果。
因此，傳遞 map 時，如果想修改map的內容而不是map本身，函數形參無需使用指針
map 底層數據結構是通過指針指向實際的元素 存儲空間 ，這種情況下，對其中一個map的更改，會影響到其他map
map 在沒有被修改的情況下，使用 range 多次遍歷 map 時輸出的 key 和 value 的順序可能不同。這是 Go 語言的設計者們有意為之，在每次 range 時的順序被隨機化，旨在提示開發者們，Go 底層實現並不保證 map 遍歷順序穩定，請大家不要依賴 range 遍歷結果順序。
map 本身是無序的，且遍歷時順序還會被隨機化，如果想順序遍歷 map，需要對 map key 先排序，再按照 key 的順序遍歷 map。
map默認是並發不安全的，原因如下：
Go 官方在經過了長時間的討論後，認為 Go map 更應適配典型使用場景（不需要從多個 goroutine 中進行安全訪問），而不是為了小部分情況（並發訪問），導致大部分程序付出加鎖代價（性能），決定了不支持。
場景: 2個協程同時讀和寫，以下程序會出現致命錯誤：fatal error: concurrent map writes
如果想實現map線程安全，有兩種方式：
方式一：使用讀寫鎖 map + sync.RWMutex
方式二：使用golang提供的 sync.Map
sync.map是用讀寫分離實現的，其思想是空間換時間。和map+RWLock的實現方式相比，它做了一些優化：可以無鎖訪問read map，而且會優先操作read map，倘若只操作read map就可以滿足要求(增刪改查遍歷)，那就不用去操作write map(它的讀寫都要加鎖)，所以在某些特定場景中它發生鎖競爭的頻率會遠遠小於map+RWLock的實現方式。
golang中map是一個kv對集合。底層使用hash table，用鏈表來解決衝突 ，出現衝突時，不是每一個key都申請一個結構通過鏈表串起來，而是以bmap為最小粒度掛載，一個bmap可以放8個kv。在哈希函數的選擇上，會在程序啟動時，檢測 cpu 是否支持 aes，如果支持，則使用 aes hash，否則使用 memhash。
map有3鍾初始化方式，一般通過make方式創建
map的創建通過生成彙編碼可以知道，make創建map時調用的底層函數是 runtime.makemap 。如果你的map初始容量小於等於8會發現走的是 runtime.fastrand 是因為容量小於8時不需要生成多個桶，一個桶的容量就可以滿足
makemap函數會通過 fastrand 創建一個隨機的哈希種子，然後根據傳入的 hint 計算出需要的最小需要的桶的數量，最後再使用 makeBucketArray 創建用於保存桶的數組，這個方法其實就是根據傳入的 B 計算出的需要創建的桶數量在內存中分配一片連續的空間用於存儲數據，在創建桶的過程中還會額外創建一些用於保存溢出數據的桶，數量是 2^(B-4) 個。初始化完成返回hmap指針。
找到一個 B，使得 map 的裝載因子在正常範圍內
Go 語言中讀取 map 有兩種語法：帶 comma 和 不帶 comma。當要查詢的 key 不在 map 里，帶 comma 的用法會返回一個 bool 型變量提示 key 是否在 map 中；而不帶 comma 的語句則會返回一個 value 類型的零值。如果 value 是 int 型就會返回 0，如果 value 是 string 類型，就會返回空字符串。
map的查找通過生成彙編碼可以知道，根據 key 的不同類型，編譯器會將查找函數用更具體的函數替換，以優化效率：
函數首先會檢查 map 的標誌位 flags。如果 flags 的寫標誌位此時被置 1 了，說明有其他協程在執行「寫」操作，進而導致程序 panic。這也說明了 map 對協程是不安全的。
key經過哈希函數計算後，得到的哈希值如下（主流64位機下共 64 個 bit 位）：
m: 桶的個數
從buckets 通過 hash m 得到對應的bucket，如果bucket正在擴容，並且沒有擴容完成，則從oldbuckets得到對應的bucket
計算hash所在桶編號：
用上一步哈希值最後的 5 個 bit 位，也就是 01010 ，值為 10，也就是 10 號桶（範圍是0~31號桶）
計算hash所在的槽位:
用上一步哈希值哈希值的高8個bit 位，也就是 10010111 ，轉化為十進制，也就是151，在 10 號 bucket 中尋找** tophash 值（HOB hash）為 151* 的 槽位**，即為key所在位置，找到了 2 號槽位，這樣整個查找過程就結束了。
如果在 bucket 中沒找到，並且 overflow 不為空，還要繼續去 overflow bucket 中尋找，直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket。
通過上面找到了對應的槽位，這裡我們再詳細分析下key/value值是如何獲取的：
bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 個 key 的地址就要在此基礎上跨過 i 個 key 的大小；而我們又知道，value 的地址是在所有 key 之後，因此第 i 個 value 的地址還需要加上所有 key 的偏移。
通過彙編語言可以看到，向 map 中插入或者修改 key，最終調用的是 mapassign 函數。
實際上插入或修改 key 的語法是一樣的，只不過前者操作的 key 在 map 中不存在，而後者操作的 key 存在 map 中。
mapassign 有一個系列的函數，根據 key 類型的不同，編譯器會將其優化為相應的「快速函數」。
我們只用研究最一般的賦值函數 mapassign 。
map的賦值會附帶着map的擴容和遷移，map的擴容只是將底層數組擴大了一倍，並沒有進行數據的轉移，數據的轉移是在擴容後逐步進行的，在遷移的過程中每進行一次賦值（access或者delete）會至少做一次遷移工作。
1.判斷map是否為nil
每一次進行賦值/刪除操作時，只要oldbuckets != nil 則認為正在擴容，會做一次遷移工作，下面會詳細說下遷移過程
根據上面查找過程，查找key所在位置，如果找到則更新，沒找到則找空位插入即可
經過前面迭代尋找動作，若沒有找到可插入的位置，意味着需要擴容進行插入，下面會詳細說下擴容過程
通過彙編語言可以看到，向 map 中刪除 key，最終調用的是 mapdelete 函數
刪除的邏輯相對比較簡單，大多函數在賦值操作中已經用到過，核心還是找到 key 的具體位置。尋找過程都是類似的，在 bucket 中挨個 cell 尋找。找到對應位置後，對 key 或者 value 進行「清零」操作，將 count 值減 1，將對應位置的 tophash 值置成 Empty
再來說觸發 map 擴容的時機：在向 map 插入新 key 的時候，會進行條件檢測，符合下面這 2 個條件，就會觸發擴容：
1、裝載因子超過閾值
源碼里定義的閾值是 6.5 (loadFactorNum/loadFactorDen)，是經過測試後取出的一個比較合理的因子
我們知道，每個 bucket 有 8 個空位，在沒有溢出，且所有的桶都裝滿了的情況下，裝載因子算出來的結果是 8。因此當裝載因子超過 6.5 時，表明很多 bucket 都快要裝滿了，查找效率和插入效率都變低了。在這個時候進行擴容是有必要的。
對於條件 1，元素太多，而 bucket 數量太少，很簡單：將 B 加 1，bucket 最大數量( 2^B )直接變成原來 bucket 數量的 2 倍。於是，就有新老 bucket 了。注意，這時候元素都在老 bucket 里，還沒遷移到新的 bucket 來。新 bucket 只是最大數量變為原來最大數量的 2 倍( 2^B * 2 ) 。
2、overflow 的 bucket 數量過多
在裝載因子比較小的情況下，這時候 map 的查找和插入效率也很低，而第 1 點識別不出來這種情況。表面現象就是計算裝載因子的分子比較小，即 map 里元素總數少，但是 bucket 數量多（真實分配的 bucket 數量多，包括大量的 overflow bucket）
不難想像造成這種情況的原因：不停地插入、刪除元素。先插入很多元素，導致創建了很多 bucket，但是裝載因子達不到第 1 點的臨界值，未觸發擴容來緩解這種情況。之後，刪除元素降低元素總數量，再插入很多元素，導致創建很多的 overflow bucket，但就是不會觸發第 1 點的規定，你能拿我怎麼辦？overflow bucket 數量太多，導致 key 會很分散，查找插入效率低得嚇人，因此出台第 2 點規定。這就像是一座空城，房子很多，但是住戶很少，都分散了，找起人來很困難
對於條件 2，其實元素沒那麼多，但是 overflow bucket 數特別多，說明很多 bucket 都沒裝滿。解決辦法就是開闢一個新 bucket 空間，將老 bucket 中的元素移動到新 bucket，使得同一個 bucket 中的 key 排列地更緊密。這樣，原來，在 overflow bucket 中的 key 可以移動到 bucket 中來。結果是節省空間，提高 bucket 利用率，map 的查找和插入效率自然就會提升。
由於 map 擴容需要將原有的 key/value 重新搬遷到新的內存地址，如果有大量的 key/value 需要搬遷，會非常影響性能。因此 Go map 的擴容採取了一種稱為「漸進式」的方式，原有的 key 並不會一次性搬遷完畢，每次最多只會搬遷 2 個 bucket。
上面說的 hashGrow() 函數實際上並沒有真正地「搬遷」，它只是分配好了新的 buckets，並將老的 buckets 掛到了 oldbuckets 字段上。真正搬遷 buckets 的動作在 growWork() 函數中，而調用 growWork() 函數的動作是在 mapassign 和 mapdelete 函數中。也就是插入或修改、刪除 key 的時候，都會嘗試進行搬遷 buckets 的工作。先檢查 oldbuckets 是否搬遷完畢，具體來說就是檢查 oldbuckets 是否為 nil。
如果未遷移完畢，賦值/刪除的時候，擴容完畢後（預分配內存），不會馬上就進行遷移。而是採取 增量擴容 的方式，當有訪問到具體 bukcet 時，才會逐漸的進行遷移（將 oldbucket 遷移到 bucket）
nevacuate 標識的是當前的進度，如果都搬遷完，應該和2^B的長度是一樣的
在evacuate 方法實現是把這個位置對應的bucket，以及其衝突鏈上的數據都轉移到新的buckets上。
轉移的判斷直接通過tophash 就可以，判斷tophash中第一個hash值即可
遍歷的過程，就是按順序遍歷 bucket，同時按順序遍歷 bucket 中的 key。
map遍歷是無序的，如果想實現有序遍歷，可以先對key進行排序
為什麼遍歷 map 是無序的？
如果發生過遷移，key 的位置發生了重大的變化，有些 key 飛上高枝，有些 key 則原地不動。這樣，遍歷 map 的結果就不可能按原來的順序了。
如果就一個寫死的 map，不會向 map 進行插入刪除的操作，按理說每次遍歷這樣的 map 都會返回一個固定順序的 key/value 序列吧。但是 Go 杜絕了這種做法，因為這樣會給新手程序員帶來誤解，以為這是一定會發生的事情，在某些情況下，可能會釀成大錯。
Go 做得更絕，當我們在遍歷 map 時，並不是固定地從 0 號 bucket 開始遍歷，每次都是從一個**隨機值序號的 bucket 開始遍歷，並且是從這個 bucket 的一個 隨機序號的 cell **開始遍歷。這樣，即使你是一個寫死的 map，僅僅只是遍歷它，也不太可能會返回一個固定序列的 key/value 對了。
golang獲取postman傳遞數據的方法
http.request的三個屬性Form、PostForm、MultipartForm:
Form：存儲了post、put和get參數，在使用之前需要調用ParseForm方法。
PostForm：存儲了post、put參數，在使用之前需要調用ParseForm方法。
MultipartForm：存儲了包含了文件上傳的表單的post參數，在使用前需要調用ParseMultipartForm方法。
獲取Get參數
用postman測試，提交，服務端輸出 ：[111]，提交： ;uid=222。服務端輸出：[111 222]
小結：r.Form是url.Values字典類型，r.Form[「id」]取到的是一個數組類型。因為http.request在解析參數的時候會將同名的參數都放進同一個數組裡。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/259209.html
微信掃一掃 
支付寶掃一掃 