goland map底层原理

Posted 2023-04-23

参考技术A map 是Go语言中基础的数据结构，在日常的使用中经常被用到。但是它底层是如何实现的呢？

总体来说golang的map是hashmap，是使用数组+链表的形式实现的，使用拉链法消除hash冲突。

golang的map由两种重要的结构，hmap和bmap(下文中都有解释)，主要就是hmap中包含一个指向bmap数组的指针，key经过hash函数之后得到一个数，这个数低位用于选择bmap(当作bmap数组指针的下表)，高位用于放在bmap的[8]uint8数组中，用于快速试错。然后一个bmap可以指向下一个bmap(拉链)。

Golang中map的底层实现是一个散列表，因此实现map的过程实际上就是实现散表的过程。在这个散列表中，主要出现的结构体有两个，一个叫 hmap (a header for a go map)，一个叫 bmap (a bucket for a Go map，通常叫其bucket)。这两种结构的样子分别如下所示：

hmap :

图中有很多字段，但是便于理解map的架构，你只需要关心的只有一个，就是标红的字段： buckets数组 。Golang的map中用于存储的结构是bucket数组。而bucket(即bmap)的结构是怎样的呢？

bucket ：

相比于hmap，bucket的结构显得简单一些，标红的字段依然是“核心”，我们使用的map中的key和value就存储在这里。“高位哈希值”数组记录的是当前bucket中key相关的“索引”，稍后会详细叙述。还有一个字段是一个指向扩容后的bucket的指针，使得bucket会形成一个链表结构。例如下图：

由此看出hmap和bucket的关系是这样的：

而bucket又是一个链表，所以，整体的结构应该是这样的：

哈希表的特点是会有一个哈希函数，对你传来的key进行哈希运算，得到唯一的值，一般情况下都是一个数值。Golang的map中也有这么一个哈希函数，也会算出唯一的值，对于这个值的使用，Golang也是很有意思。

Golang把求得的值按照用途一分为二：高位和低位。

如图所示，蓝色为高位，红色为低位。 然后低位用于寻找当前key属于hmap中的哪个bucket，而高位用于寻找bucket中的哪个key。上文中提到：bucket中有个属性字段是“高位哈希值”数组，这里存的就是蓝色的高位值，用来声明当前bucket中有哪些“key”，便于搜索查找。 需要特别指出的一点是：我们map中的key/value值都是存到同一个数组中的。数组中的顺序是这样的:

并不是key0/value0/key1/value1的形式，这样做的好处是：在key和value的长度不同的时候，可 以消除padding(内存对齐)带来的空间浪费 。

现在，我们可以得到Go语言map的整个的结构图了：(hash结果的低位用于选择把KV放在bmap数组中的哪一个bmap中，高位用于key的快速预览，用于快速试错)

map的扩容

当以上的哈希表增长的时候，Go语言会将bucket数组的数量扩充一倍，产生一个新的bucket数组，并将旧数组的数据迁移至新数组。

加载因子

判断扩充的条件，就是哈希表中的加载因子(即loadFactor)。

加载因子是一个阈值，一般表示为：散列包含的元素数 除以 位置总数。是一种“产生冲突机会”和“空间使用”的平衡与折中：加载因子越小，说明空间空置率高，空间使用率小，但是加载因子越大，说明空间利用率上去了，但是“产生冲突机会”高了。

每种哈希表的都会有一个加载因子，数值超过加载因子就会为哈希表扩容。

Golang的map的加载因子的公式是：map长度 / 2^B(这是代表bmap数组的长度，B是取的低位的位数)阈值是6.5。其中B可以理解为已扩容的次数。

当Go的map长度增长到大于加载因子所需的map长度时，Go语言就会将产生一个新的bucket数组，然后把旧的bucket数组移到一个属性字段oldbucket中。注意：并不是立刻把旧的数组中的元素转义到新的bucket当中，而是，只有当访问到具体的某个bucket的时候，会把bucket中的数据转移到新的bucket中。

如下图所示：当扩容的时候，Go的map结构体中，会保存旧的数据，和新生成的数组

上面部分代表旧的有数据的bucket，下面部分代表新生成的新的bucket。蓝色代表存有数据的bucket，橘黄色代表空的bucket。

扩容时map并不会立即把新数据做迁移，而是当访问原来旧bucket的数据的时候，才把旧数据做迁移，如下图：

注意：这里并不会直接删除旧的bucket，而是把原来的引用去掉，利用GC清除内存。

map中数据的删除

如果理解了map的整体结构，那么查找、更新、删除的基本步骤应该都很清楚了。这里不再赘述。

值得注意的是，找到了map中的数据之后，针对key和value分别做如下操作：

1

2

3

4

1、如果``key``是一个指针类型的，则直接将其置为空，等待GC清除；

2、如果是值类型的，则清除相关内存。

3、同理，对``value``做相同的操作。

4、最后把key对应的高位值对应的数组index置为空。

Git系列之底层原理篇

参考技术A

本章节是Git的核心知识点，主要是介绍Git底层原理与在使用Git过程中的几个重要区域，弄懂Git的整个使用流程，以及数据的存储过程。

工作区（Working Directory）:

工作区就是我们平时编写文本文件的地方

暂存区（Stage/Index）:

暂存区是我们提交文本文件到本地仓库的来源地，只有把工作区的文件添加至暂存区，才可以被提交至本地仓库。

本地仓库（Repository）：

本地仓库是保存每次文件更新的记录，包括提交人，提交时间，提交的内容等详细信息，方便追溯历史版本。

远程仓库（Remote Repository）：

远程仓库算是本地仓库的一个副本，主要是方便合作伙伴之间的仓库文件同步。

因此它的使用流程可以简单的概括为：

1、在本地搭建一个目录，用来创建git仓库

$ git init gitDirectory

2、在仓库目录下创建文本文件（工作区）

$ cd gitDirectory

$ echo "first txt" > first.txt

3、把工作区的first.txt文件添加至git暂存区

$ git add first.txt

4、将暂存区中的文件first.txt提交至本地仓库

$ git commit -m "first commit"

5、将文件保存至本地仓库就已经可以记录我们每次提交的历史信息了，但是为了方便其他伙伴一起协作，还需要搭建一个远程服务。（本次以GitHub为例）

在GitHub创建一个和本地一样名称的仓库，创建成功后会生成一个仓库地址：

https://github.com/mr-kings/gitDirectory.git

6、将本地仓库和远程仓库关联起来

$ git remote add origin https://github.com/mr-kings/gitDirectory.git

7、第一次将本地仓库提交至远程仓库

$ git push -u origin master

第一次需要添加 -u 参数，即把本地的master分支和远程仓库的master分支对应上

8、此时本地仓库和远程仓库就已经实现了同步，其他协作伙伴只需到远程仓库把仓库克隆到自己的电脑即可进行协作编辑

$ git clone https://github.com/mr-kings/gitDirectory.git

9、克隆下来以后会在本地生成本地仓库以及工作区，后续的操作和2步骤及以后步骤一致

需要注意的是：远程仓库有两种连接方式https/ssh，上面的例子使用的https，其实ssh方式会比https快的多，它还可以通过添加密钥的方式省去每次提交时都要输入用户名和密码的问题，这里不做详细介绍。https也是可以通过配置省去每次推送都需要输入用户名和密码的问题。

Git安装成功后，在本地新建一个Git仓库，$ git init Gitstudy会生成一个.git文件夹，如果你创建的时候没有发现.git目录那应该是你的电脑默认隐藏了.git文件夹，有两种方式可以查看它：

第一种方式：

命令行工具，在当前目录下，在命令行里输入 $ ll -a 即可查看

第二种方式：

在当前目录下，点击查看菜单，然后勾选上隐藏的项目即可

.git目录就是暂存区和本地仓库的位置，所以它的核心就在这里，下面看看它有哪些内容：

由上图可知，初始化的时候.git目录下有以下文件及文件夹：

config(文件)：存放当前仓库的一些配置信息，比如记住用户名和密码，别名等

下面是它的常用选项：

[core] ignorecase 是否忽略文件大小写

[remote "origin"] url 配置远程仓库地址

[remote "origin"] fetch 远程分支映射关系

[user] name 用户名

[user] email 邮箱

[alias] 命令别名配置 ： cmt = commit

description(文件)：创建仓库的描述文件

HEAD(文件)：指示当前被检出(所在)的分支，如当前在test分支，文件内容则为ref: refs/heads/test。

hooks/(文件夹)：包含客户端或服务端的钩子脚本(hook scripts)，如pre-commit，post-receive等

info/ (文件夹)：用以存储一些有关git仓库的信息，如exclude

objects/ (文件夹)：用以存储git仓库中的所有数据内容

refs/(文件夹)：包含 heads 文件夹，remote文件夹。heads 记录本地相关的各 git分支操作记录，remote 记录远程仓库相关的各git分支 操作记录

当第一次提交的时候还会生成以下文件及文件夹：

index (文件) -- （在git add file的时候生成）：是当前版本的文件索引，包含生成当前树(唯一确定的)对象的所虚信息，可用于快速比对工作树和其他提交树对象的差异(各commit和HEAD之间的diff)，可用于存储单文件的多个版本以有效的解决合并冲突。可使用git ls-files 查看index文件内容

COMMIT_EDITMSG(文件) -- （在git commit -m "first commit"的时候生成）：最近一次的 commit edit message

logs/ (文件夹) -- （在git commit -m "first commit"的时候生成）：放置git仓库操作记录的文件夹，包含HEAD文件 和 refs文件夹

以上简单介绍了.git目录下的文件及文件夹，重点则是objects文件夹：

经过第一次提交后objects文件夹下多出了3个文件夹：44/、d0/、f6/。通过提交的日志我们发现，commit后会生成一个40位的16进制字符串（前两位作为文件夹名称，后38位为内容哈希值）

官方描述：这是一个 SHA-1 哈希值——一个将待存储的数据外加一个头部信息(header)一起做 SHA-1 校验运算而得的校验和（前2位作为文件夹名称 -- 后面38位作为内容的哈希值）

通过cat-file -t sha-1 命令查看当前哈希值所属的类型：

由图可知它是一个commit对象

再通过命令cat-file -p sha-1查看该commit对象包含有哪些信息

由图知一个commit对象包含了tree对象，本地仓库信息，提交人信息及提交时的备注信息。

再通过上述命令查看tree对象又包含又哪些信息：

由图知tree对象又包含了blob对象，在多目录的情况下tree对象还会包含其他tree对象。

由此得出结论：刚才提交的时候生成的那个3个文件夹分别对应的是3个对象即：44/文件夹对应的是commit对象，f6/文件夹对应的是tree对象，d0/文件夹对应的是blob对象。层级关系是：commit对象对应一个tree对象，tree对象可以包含一个或多个其他tree对象和blob对象。

下面就简单介绍git中的几个对象：

blob：

blob对象只跟文本文件的内容有关，和文本文件的名称及目录无关，只要是相同的文本文件，会指向同一个blob。

tree:

tree对象记录文本文件内容和名称、目录等信息，每次提交都会生成一个顶层tree对象，它可以指向其引用的tree或blob。

commit:

commit对象记录本次提交的所有信息，包括提交人、提交时间，本次提交包含的tree及blob。

tag:

标签引用，它指向某一个commit。

用下面的图可以把今天的内容概括起来：上半部分描述了git的操作流程图，下半部分描述git底层数据存储结构图

Git流程及底层结构图

下面就对图的下半部分做个详细说明：

1、在与.git同级目录下新建文件夹directory，再在directory目录下新建一个文本文件first.txt，里面的内容为1。当执行$ git add first.txt 的时候就会在.git/objects/生成一个blob对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的第一个d00491 -- blob对象。

2、当执行$ git commit -m "first commit" 的时候就会在.git/objects/下新生成了2个tree对象和一个commit对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的f6589b -- tree对象,4a2e3e -- tree对象,6b18a7 -- commit对象。之所以生成两个tree对象是因为directory目录为一个tree对象还有与commit对象一一对应的顶层tree对象。这个时候HEAD游标指向的是当前master分支的first commit。并且在这次提交的时候打个v1.0版本的标签。

3、在与.git同级目录下新建一个新的文本文件second.txt，内容为2。当执行$ git add second.txt 的时候就会在.git/objects/生成一个新的blob对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的0cfbf0 -- blob对象。

4、当执行$ git commit -m "second commit" 的时候就会在.git/objects/下新生成了1个tree对象和一个commit对象的文件夹（前两位为文件夹名称 -- 后38位为文本内容的哈希值）对应上图的35e40c -- tree对象,d6dca9 -- commit对象。只生成一个与commit对象一一对应的顶层tree对象。由于本次提交directory目录下的first.txt内容没有变化，所以上图的35e40c -- tree对象还会指向f6589b -- tree对象。这个时候HEAD游标指向的是当前master分支的second commit(HEAD索引向前移动)，second commit 会指向上一次的提交即 parent指向first commit。

后续的操作以此类推，但需要注意的点是：

1、blob对象只对文件的内容有关，和文件名称无关，如果不同的文件名称，内容相同只会有一个blob对象，生成的新tree对象会指向该blob对象。例如上图的third.txt和four.txt里面的内容都为3。所以不会生成新的blob对象，新的tree对象只会指向同一个blob。

2、如果每次提交的时候包含的某些文件并没有改动（更新），那么就会直接指向它原来的索引，不会重新生成。例如上图的directory/first.txt，second.txt

3、每次commit对象都会和顶层的tree对象一一对应。