Go的map字典及约束

Posted 2022-11-26 技术能量站

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Go的map字典及约束相关的知识，希望对你有一定的参考价值。

1、前言

到目前为止，我们看过的集合类的高级数据类型都属于针对单一元素的容器。它们或用连续存储，或用互存指针的方式收纳元素，这里的每个元素都代表了一个从属某一类型的独立值。

我们今天要讲的字典（map）却不同，它能存储的不是单一值的集合，而是键值对的集合。

什么是键值对？它是从英文 key-value pair 直译过来的一个词。
顾名思义，一个键值对就代表了一对键和值。注意，一个“键”和一个“值”分别代表了一个从属于某一类型的独立值，把它们两个捆绑在一起就是一个键值对了。

在 Go 语言规范中，应该是为了避免歧义，他们将键值对换了一种称呼，叫做：“键 - 元素对”。我们也沿用这个看起来更加清晰的词来讲解。

1.1 为什么字典的键类型会受到约束？

Go 语言的字典类型其实是一个哈希表（hash table）的特定实现，在这个实现中，键和元素的最大不同在于，键的类型是受限的，而元素却可以是任意类型的。

如果要探究限制的原因，我们就先要了解哈希表中最重要的一个过程：映射。

你可以把键理解为元素的一个索引，我们可以在哈希表中通过键查找与它成对的那个元素。

键和元素的这种对应关系，在数学里就被称为“映射”，这也是“map”这个词的本意，哈希表的映射过程就存在于对键 - 元素对的增、删、改、查的操作之中。

aMap := map[string]int
  "one":    1,
  "two":    2,
  "three": 3,

k := "two"
v, ok := aMap[k]
if ok 
  fmt.Printf("The element of key %q: %d\\n", k, v)
 else 
  fmt.Println("Not found!")

比如，我们要在哈希表中查找与某个键值对应的那个元素值，那么我们需要先把键值作为参数传给这个哈希表。

哈希表会先用哈希函数（hash function）把键值转换为哈希值。哈希值通常是一个无符号的整数。一个哈希表会持有一定数量的桶（bucket），我们也可以叫它哈希桶，这些哈希桶会均匀地储存其所属哈希表收纳的键 - 元素对。

因此，哈希表会先用这个键哈希值的低几位去定位到一个哈希桶，然后再去这个哈希桶中，查找这个键。

由于键 - 元素对总是被捆绑在一起存储的，所以一旦找到了键，就一定能找到对应的元素值。随后，哈希表就会把相应的元素值作为结果返回。

只要这个键 - 元素对存在哈希表中就一定会被查找到，因为哈希表增、改、删键 - 元素对时的映射过程，与前文所述如出一辙。

现在我们知道了，映射过程的第一步就是：把键值转换为哈希值。

在 Go 语言的字典中，每一个键值都是由它的哈希值代表的。也就是说，字典不会独立存储任何键的值，但会独立存储它们的哈希值。

你是不是隐约感觉到了什么？我们接着往下看。

我们今天的问题是：字典的键类型不能是哪些类型？

这个问题你可以在 Go 语言规范中找到答案，但却没那么简单。它的典型回答是：Go 语言字典的键类型不可以是函数类型、字典类型和切片类型。

问题解析

我们来解析一下这个问题。

Go 语言规范规定，在键类型的值之间必须可以施加操作符==和!=。换句话说，键类型的值必须要支持判等操作。由于函数类型、字典类型和切片类型的值并不支持判等操作，所以字典的键类型不能是这些类型。

另外，如果键的类型是接口类型的，那么键值的实际类型也不能是上述三种类型，否则在程序运行过程中会引发 panic（即运行时恐慌）。

我们举个例子：

var badMap2 = map[interface]int
  "1":   1,
  []int2: 2, // 这里会引发panic。
  3:    3,

这里的变量badMap2的类型是键类型为interface、值类型为int的字典类型。这样声明并不会引起什么错误。或者说，我通过这样的声明躲过了 Go 语言编译器的检查。

注意，我用字面量在声明该字典的同时对它进行了初始化，使它包含了三个键 - 元素对。其中第二个键 - 元素对的键值是[]int2，元素值是2。这样的键值也不会让 Go 语言编译器报错，因为从语法上说，这样做是可以的。

但是，当我们运行这段代码的时候，Go 语言的运行时（runtime）系统就会发现这里的问题，它会抛出一个 panic，并把根源指向字面量中定义第二个键 - 元素对的那一行。我们越晚发现问题，修正问题的成本就会越高，所以最好不要把字典的键类型设定为任何接口类型。如果非要这么做，请一定确保代码在可控的范围之内。

还要注意，如果键的类型是数组类型，那么还要确保该类型的元素类型不是函数类型、字典类型或切片类型。

比如，由于类型[1][]string的元素类型是[]string，所以它就不能作为字典类型的键类型。另外，如果键的类型是结构体类型，那么还要保证其中字段的类型的合法性。无论不合法的类型被埋藏得有多深，比如map[[1][2][3][]string]int，Go 语言编译器都会把它揪出来。

你可能会有疑问，为什么键类型的值必须支持判等操作？我在前面说过，Go 语言一旦定位到了某一个哈希桶，那么就会试图在这个桶中查找键值。具体是怎么找的呢？

首先，每个哈希桶都会把自己包含的所有键的哈希值存起来。Go 语言会用被查找键的哈希值与这些哈希值逐个对比，看看是否有相等的。如果一个相等的都没有，那么就说明这个桶中没有要查找的键值，这时 Go 语言就会立刻返回结果了。

如果有相等的，那就再用键值本身去对比一次。为什么还要对比？原因是，不同值的哈希值是可能相同的。这有个术语，叫做“哈希碰撞”。

所以，即使哈希值一样，键值也不一定一样。如果键类型的值之间无法判断相等，那么此时这个映射的过程就没办法继续下去了。最后，只有键的哈希值和键值都相等，才能说明查找到了匹配的键 - 元素对。

2、实现原理

下面通过探究在golang 中map的数据结构及源码实现来学习和了解map的特性，共包含map的模型探究、存取、扩容等内容。

2.1 Map 的底层模型

在 golang 的源码中表示 map 的底层 struct 是 hmap，其是 hashmap 的缩写

type hmap struct 
 
   // map中存入元素的个数， golang中调用len(map)的时候直接返回该字段
   count     int
   // 状态标记位，通过与定义的枚举值进行&操作可以判断当前是否处于这种状态
   flags     uint8
   B         uint8  // 2^B 表示bucket的数量， B 表示取hash后多少位来做bucket的分组
   noverflow uint16 // overflow bucket 的数量的近似数
   hash0     uint32 // hash seed （hash 种子） 一般是一个素数
 
   buckets    unsafe.Pointer // 共有2^B个 bucket ，但是如果没有元素存入，这个字段可能为nil
   oldbuckets unsafe.Pointer // 在扩容期间，将旧的bucket数组放在这里， 新buckets会是这个的两倍大
   nevacuate  uintptr        // 表示已经完成扩容迁移的bucket的指针， 地址小于当前指针的bucket已经迁移完成
 
   extra *mapextra // optional fields

B 是 buckets 数组的长度的对数，即 bucket 数组的长度是 2^B。bucket 的本质上是一个指针，指向了一片内存空间，其指向的 struct 如下所示：

// A bucket for a Go map.
type bmap struct 
   tophash [bucketCnt]uint8

但这只是表面(src/runtime/hashmap.go)的结构，编译期间会给它加料，动态地创建一个新的结构：

type bmap struct 
    topbits  [8]uint8
    keys     [8]keytype
    values   [8]valuetype
    pad      uintptr        // 内存对齐使用，可能不需要
    overflow uintptr        // 当bucket 的8个key 存满了之后

bmap 就是我们常说的“桶”的底层数据结构，一个桶中可以存放最多 8 个 key/value, map 使用 hash 函数得到 hash 值决定分配到哪个桶，然后又会根据 hash 值的高 8 位来寻找放在桶的哪个位置具体的 map 的组成结构如下图所示：

2.2 Map 的存取

在 map 中存与取本质上都是在进行一个工作，那就是:

查询当前 k/v 应该存储的位置。
赋值/取值，所以我们理解了 map 中 key 的定位我们就理解了存取。

1、底层代码

func mapaccess2(t *maptype, h *hmap, key unsafe.Pointer) (unsafe.Pointer, bool) 
    // map 为空，或者元素数为 0，直接返回未找到
    if h == nil || h.count == 0 
        return unsafe.Pointer(&zeroVal[0]), false
    
    // 不支持并发读写
    if h.flags&hashWriting != 0 
        throw("concurrent map read and map write")
    
    // 根据hash 函数算出hash值，注意key的类型不同可能使用的hash函数也不同
    hash := t.hasher(key, uintptr(h.hash0))
    // 如果 B = 5，那么结果用二进制表示就是 11111 ， 返回的是B位全1的值
    m := bucketMask(h.B)
    // 根据hash的后B位，定位在bucket数组中的位置
    b := (*bmap)(unsafe.Pointer(uintptr(h.buckets) + (hash&m)*uintptr(t.bucketsize)))
    // 当 h.oldbuckets 非空时，说明 map 发生了扩容
    // 这时候，新的 buckets 里可能还没有老的内容
    // 所以一定要在老的里面找，否则有可能发生“消失”的诡异现象
    if c := h.oldbuckets; c != nil 
        if !h.sameSizeGrow() 
            // 说明之前只有一半的 bucket，需要除 2
            m >>= 1
        
        oldb := (*bmap)(unsafe.Pointer(uintptr(c) + (hash&m)*uintptr(t.bucketsize)))
        if !evacuated(oldb) 
            b = oldb
        
    
    // tophash 取其高 8bit 的值
    top := tophash(hash)
    // 一个 bucket 在存储满 8 个元素后，就再也放不下了，这时候会创建新的 bucket，挂在原来的 bucket 的 overflow 指针成员上
    // 遍历当前bucket的所有链式bucket
    for ; b != nil; b = b.overflow(t) 
        // 在bucket的8个位置上查询
        for i := uintptr(0); i < bucketCnt; i++ 
            // 如果找到了相等的 tophash，那说明就是这个 bucket 了
            if b.tophash[i] != top 
                continue
            
            // 根据内存结构定位key的位置
            k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
            if t.indirectkey 
                k = *((*unsafe.Pointer)(k))
            
            // 校验找到的key是否匹配
            if t.key.equal(key, k) 
                // 定位v的位置
                v := add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.valuesize))
                if t.indirectvalue 
                    v = *((*unsafe.Pointer)(v))
                
                return v, true
            
        
    
 
    // 所有 bucket 都没有找到，返回零值和 false
    return unsafe.Pointer(&zeroVal[0]), false

2、寻址过程

2.3 Map的扩容

在 golang 中 map 和 slice 一样都是在初始化时首先申请较小的内存空间，在 map 的不断存入的过程中，动态的进行扩容。扩容共有两种，增量扩容与等量扩容（重新排列并分配内存）。下面我们来了解一下扩容的触发方式：

负载因子超过阈值，源码里定义的阈值是 6.5。(触发增量扩容)
overflow 的 bucket 数量过多：当 B 小于 15，也就是 bucket 总数 2^B 小于 2^15 时，如果 overflow 的 bucket 数量超过 2^B；当 B >= 15，也就是 bucket 总数 2^B 大于等于 2^15，如果 overflow 的 bucket 数量超过 2^15。（触发等量扩容）

1、增量扩容

2、等量扩容

先说结论，在 golang 中 map 是无序的，准确的说是无法严格保证顺序的，从上面的源码中我们可以知道，golang 中 map 在扩容后，可能会将部分 key 移至新内存，由于在扩容搬移数据过程中，并未记录原数据位置，并且在 golang 的数据结构中也并未保存数据的顺序，所以那么这一部分在扩容后实际上就已经是无序的了。

遍历的过程，其实就是按顺序遍历内存地址，同时按顺序遍历内存地址中的 key。但这时已经是无序的了。但是如果我就一个 map，我保证不会对 map 进行修改删除等操作，那么按理说没有扩容就不会发生改变。但也是因为这样，GO 才在源码中但是有一个有趣的现象，就算不对 map 进行插入删除等操作致使其扩容，其在遍历过程中仍是无序的。

objMap := make(map[string]int)
for i := 0; i < 5; i++ 
   objMap[strconv.Itoa(i)] = i

for i := 0 ; i < 5; i ++ 
   var valStr1, valStr2 string
   for k, v := range objMap 
      fmt.Println(k)
      fmt.Println(v)
      valStr1 += k
   
   for k, v := range objMap 
      fmt.Println(k)
      fmt.Println(v)
      valStr2 += k
   
   fmt.Println(valStr1 == valStr2)
   if valStr1 != valStr2 
      fmt.Println("not equal")
   

fmt.Println("end")

以上的运行结果是

不难看出，即使不对 map 进行扩容，在多次遍历时也是无序的，这是因为 golang 官方在设计时故意加上随机的元素，将遍历 map 的顺序随机化，用来防止使用者用来顺序遍历。
依赖 map 的顺序进行遍历，这是有风险的代码，在 GO 的严格语法规则下，是坚决不提倡的。所以我们在使用 map 时一定要记得其是无序的，不要依赖其顺序。

2.4 Map的并发

首先我们大家都知道，在 golang 中 map 并不是一个并发安全的数据结构，当几个 goruotine 同时对一个 map 进行读写操作时，就会出现并发写问题：fatal error: concurrent map writes。但是为什么 map 是不支持并发安全的呢，主要是因为成本与效益。
官方答复原因如下：

典型使用场景：map 的典型使用场景是不需要从多个 goroutine 中进行安全访问。
非典型场景（需要原子操作）：map 可能是一些更大的数据结构或已经同步的计算的一部分。

性能场景考虑：若是只是为少数程序增加安全性，导致 map 所有的操作都要处理 mutex，将会降低大多数程序的性能。同时 golang 提供了并发安全的 sync map。

， // 不支持并发读写
    if h.flags&hashWriting != 0 
        throw("concurrent map read and map write")

但是我们又有疑问了，为什么 golang map 并发冲突了不抛一个 error 出来，或者 panic 掉，而是要让程序 panic，选择让程序 crash 崩溃掉。这里是 golang 官方出于权衡风险和 map 使用复杂度场景考虑的，首先 map 在官方中就明确表示不支持并发读写，所以并发对 map 进行读写操作本身就是不正确的。

场景假设一：如果 map 选择在写入或者读取时增加 error 返回值，会导致程序在使用 map 时就无法像现在一样，需要额外的捕获并判断 err。
场景假设二：如果 map 选择 panic（可被 recover），此时如果出现并发写入数据的场景，就会导致走进 recover 中，如果没有对这种场景进行特殊处理，就会导致 map 中存在脏数据，此时程序在使用 map 时就会引发不可预知的错误，此时排查起来也是很难找到问题的根因的。

所以 golang 在考虑了这些场景后，选择明确的抛出 crash 崩溃异常，使得风险被提前暴露。可以明确的定位到问题点。综上所述我们在使用 map 时，已经要严格保障其是在单线程内使用的，如果有多线程场景，建议使用 sync map 。

3、总结

我们这次主要讨论了与字典类型有关的，一些容易让人困惑的问题。比如，为什么字典的键类型会受到约束？又比如，我们通常应该选取什么样的类型作为字典的键类型。

我以 Go 语言规范为起始，并以 Go 语言源码为依据回答了这些问题。认真看了这篇文章之后，你应该对字典中的映射过程有了一定的理解。

另外，对于 Go 语言在那些合法的键类型上所做的求哈希和判等的操作，你也应该有所了解了。

再次强调，永远要注意那些可能引发 panic 的操作，比如像一个值为nil的字典添加键 - 元素对。

4、知识拓展

问题 1：应该优先考虑哪些类型作为字典的键类型？

你现在已经清楚了，在 Go 语言中，有些类型的值是支持判等的，有些是不支持的。那么在这些值支持判等的类型当中，哪些更适合作为字典的键类型呢？

这里先抛开我们使用字典时的上下文，只从性能的角度看。在前文所述的映射过程中，“把键值转换为哈希值”以及“把要查找的键值与哈希桶中的键值做对比”，明显是两个重要且比较耗时的操作。

因此，可以说，求哈希和判等操作的速度越快，对应的类型就越适合作为键类型。

对于所有的基本类型、指针类型，以及数组类型、结构体类型和接口类型，Go 语言都有一套算法与之对应。这套算法中就包含了哈希和判等。以求哈希的操作为例，宽度越小的类型速度通常越快。对于布尔类型、整数类型、浮点数类型、复数类型和指针类型来说都是如此。对于字符串类型，由于它的宽度是不定的，所以要看它的值的具体长度，长度越短求哈希越快。

类型的宽度是指它的单个值需要占用的字节数。比如，bool、int8和uint8类型的一个值需要占用的字节数都是1，因此这些类型的宽度就都是1。

以上说的都是基本类型，再来看高级类型。对数组类型的值求哈希实际上是依次求得它的每个元素的哈希值并进行合并，所以速度就取决于它的元素类型以及它的长度。细则同上。

我不建议你使用这些高级数据类型作为字典的键类型，不仅仅是因为对它们的值求哈希，以及判等的速度较慢，更是因为在它们的值中存在变数。比如：

对一个数组来说，我可以任意改变其中的元素值，但在变化前后，它却代表了两个不同的键值。
对于结构体类型的值情况可能会好一些，因为如果我可以控制其中各字段的访问权限的话，就可以阻止外界修改它了。把接口类型作为字典的键类型最危险。

还记得吗？如果在这种情况下 Go 运行时系统发现某个键值不支持判等操作，那么就会立即抛出一个 panic。在最坏的情况下，这足以使程序崩溃。

那么，在那些基本类型中应该优先选择哪一个？答案是，优先选用数值类型和指针类型，通常情况下类型的宽度越小越好。如果非要选择字符串类型的话，最好对键值的长度进行额外的约束。

那什么是不通常的情况？笼统地说，Go 语言有时会对字典的增、删、改、查操作做一些优化。比如：

在字典的键类型为字符串类型的情况下；
在字典的键类型为宽度为4或8的整数类型的情况下。

问题 2：在值为nil的字典上执行读操作会成功吗，那写操作呢？

由于字典是引用类型，所以当我们仅声明而不初始化一个字典类型的变量的时候，它的值会是nil。

在这样一个变量上试图通过键值获取对应的元素值，或者添加键 - 元素对，会成功吗？这个问题虽然简单，但却是我们必须铭记于心的，因为这涉及程序运行时的稳定性。

我来说一下答案。除了添加键 - 元素对，我们在一个值为nil的字典上做任何操作都不会引起错误。当我们试图在一个值为nil的字典中添加键 - 元素对的时候，Go 语言的运行时系统就会立即抛出一个 panic。你可以运行一下 demo19.go 文件试试看。