本文永久链接 – https://tonybai.com/2024/01/06/the-2024-review-of-go-programming-language

2024年底，由于感染了甲流，我在家卧床休息了两天，原定于2024年进行的Go语言盘点写作因此被迫推迟。不过，我始终相信：迟到但不会缺席。在2025年元旦的第一天，我终于开始了这篇博客的撰写。

时间过得真快，《2023年Go语言盘点：稳中求新，稳中求变》依然历历在目。转眼之间，一年365天过去了，发生了许多事情，甚至有些记忆已在脑海中模糊或消逝。在这里，我将带你盘点那些关于Go的重要时刻，唤起你对Go的美好回忆。

回顾整个2024年，如果非要用一句话来形容Go语言的状态，我会选择：Go完成了技术成熟度曲线中的“稳步爬升复苏期”，开始进入“生产成熟期”。这一点在Go的排名中得到了直接体现，并在Go社区的活跃度方面得到了间接的印证。而Go的年中换帅似乎也预示着这是一个新的起点！在过去一年中，得益于Go团队和社区的共同努力，Go发布了许多值得关注的新特性。

接下来，我将为大家逐一详细介绍！

1. Go排名创历史新高

说到编程语言排名，程序员们首先想到的就是TIOBE！在2024年的TIOBE排行榜上，尽管Go语言没有像AI时代的霸主语言Python那样耀眼，但跻身前十并站稳第七名这一成绩也足以让其他语言羡慕不已！

而从2009年开源至今，Go在TIOBE排名走势如下：

了解Go历史的朋友都知道，Go语言真正具备生产级成熟度是从2015年的Go 1.5版本开始的。按照技术成熟度曲线的划分，2015年之前及其后的一段时间可以视为技术萌芽期。从曲线中可以看出，2017年时达到了期望膨胀期的峰值。此后，Go经历了一段“漫长”的泡沫破裂低谷期以及稳步爬升的复苏期。从2023年开始，到2024年末，Go语言复苏的速度日益加快！目前来看，如无意外，Go将进入技术成熟度曲线的下一阶段：生产成熟期！我曾提到过：绝大多数主流编程语言将在其诞生后的第15至第20年间大步前进。按照这个编程语言的一般规律，刚刚迈过开源第15个年头的Go刚刚迈进自己的黄金5-10年。

当然，单看TIOBE单一榜单似乎说服力不足，我们再来看看今年的Github octoverse报告。在这份报告中，Go依旧稳居github热门编程语言前10(如下图)，这一位置已经保持了三年多了！

此外，在2024年年中发布的“IEEE Spectrum 2024编程语言排行榜”中，Go在Spectrum排名和Trending排名中分列第8位和第7位。

除了排行榜之外，通过Reddit中编程语言论坛的活跃度也可以看出Go语言在全球的受欢迎程度和用户广度。以下是2025年1月1日Reddit上最活跃的9门编程语言子论坛的实时状态截图：

我们看到Go子论坛在成员数量和某一时刻的在线人数上都表现良好。此外，如果你是长期关注Reddit Go论坛的Gopher，一定注意到自2024年初以来，Go论坛的人气迅速增长，日均帖子数相比前两年显著增加，其中很多都是新加入Go阵营的初学者！

注：Rust的人气是真高啊，online人数断崖领先！

编程语言技术大会是衡量语言流行度和受欢迎程度的另一重要风向标。自从全球从新冠疫情中恢复后，GopherCon逐渐在各地线下恢复，到了2024年基本回到了疫情前的状态，甚至在一些地方的GopherCon还超越了以往的受欢迎程度。例如，2024年GopherCon欧洲大会破例举办了两次。此外，首届在非洲举行的GopherCon Africa也于2024年10月份在肯尼亚首都内罗毕成功举行！唯一的遗憾是GopherChina在2024年缺席，这或许与国内的经济形势有关。

Go的增长趋势来的有些快，不知道是否是得益于AI应用的快速发展！但就像Go团队前成员Jaana Dogan(Rakyll)所说的那样：

Go将成为AI时代重要的AI应用开发语言！AI大模型三强：OpenAI、Claude和Google都提供了对Go SDK的官方支持：

• OpenAI Go SDK – https://github.com/openai/openai-go
• Claude GO SDK – https://github.com/anthropics/anthropic-sdk-go
• Google AI Go SDK – https://github.com/google/generative-ai-go

此外，提到Go和AI大模型，我们不得不提及一个重量级的开源项目——Ollama，它可以说是当前私有部署和使用开源大模型的事实标准！在2024年的用户调查报告中，Go团队还特别关注了用户对使用Go开发AI应用的需求，并将AI应用开发视为Go应用的下一个重要赛道。此外，Russ Cox也积极参与这一领域，开源了专用于开源项目运营维护的AI机器人：Oscar，同时探索Go在AI领域的应用。

如果说Go的排名再创新高让Gopher和Go社区对Go充满了更多自信，那么Go团队的换帅则向整个编程语言界展示了团队的传承与发展！

2. Go团队换帅展示团队传承

对于Go团队来说，2024年的最大的事件不是Go 1.22或Go 1.23的发布，而是团队换帅。

2024年中旬，Go团队的技术负责人Russ Cox宣布，他将于2024年9月1日起卸任Go项目的技术领导职务。自2008年参与Go项目以来，Russ于2012年成为其技术负责人。在过去的12年里，他引领Go语言从一个实验性项目成长为当今最受欢迎的编程语言之一。在他的带领下，Go凭借简洁的语法、高效的并发模型和强大的标准库赢得了众多开发者的青睐，并在云计算、微服务和DevOps等领域得到了广泛应用。

Russ分享了他卸任的想法，表示这一决定是经过深思熟虑的，是自然发展的结果。他认为，尽管长期稳定的领导对大型项目至关重要，但领导层的变动也能为项目注入新的活力和视角。他强调，定期更换领导者是非常重要的，这有助于引入新思想并防止项目陷入停滞。

接替Russ Cox的是Austin Clements，他将成为新的Go技术负责人，同时领导Google的Go团队和整个Go项目。Austin自2014年起就在Google从事与Go相关的工作，拥有丰富的经验和深厚的技术背景。同时，Cherry Mui将接手负责编译器和运行时等“Go核心”领域的工作。Cherry自2016年加入Google，在Go的核心开发领域表现出色。Russ Cox对这两位新领导给予了高度评价，称赞他们具备卓越的判断力以及对Go语言和其运行系统的广泛而深入的理解。

通过9月份到12月份的角色过期期的观察来看，两位“新负责人”的表现是中规中矩，沿袭了Russ Cox之前确定的Go项目管理框架，Cherry Mui在Go core领域表现的十分积极，这从”Go compiler and runtime meeting notes“的记录中可见一斑！

在第333期GoTime播客中，两位新leader也初步分享了他们对后续Go演进的一些想法。

Austin强调，虽然Go保持着稳定和简洁，但它必须继续演进。他的首要目标之一是改善Go的可扩展性，无论是在开发过程中还是在背后的工程流程中。他希望通过提高透明度和扩大社区参与度，赋能社区，创建一个能够更好整合用户反馈的平台（可能是一个论坛），使贡献者能够开发与核心团队目标一致的工具和解决方案。在性能改进方面，Austin长期致力于优化Go的垃圾回收系统，目前正在试验一种新算法，幽默地称其为“绿茶”，旨在优化资源使用，进一步提升Go在越来越大系统上的扩展能力。

Cherry则指出，Go的用户基础正在快速增长，而核心团队的资源却有限。她的任务是确保Go平台能够支持这一日益增长的社区，无论是通过构建更好的API还是平台，帮助用户在Go的基础上开发更强大的工具和解决方案。在技术扩展性方面，Cherry也表达了自己的关注。随着计算能力的提升，核心数量和内存容量不断增加，Go需要适应，以高效处理更大的工作负载。Cherry表示，她非常期待与社区中的工程师合作，解决这些挑战，保持Go简单且可扩展的声誉。

从两位领导的想法与目标中，我们可以看到Go团队传承的文化。对于这样的“换帅”，Go社区应充满信心。

注：GoTime博客在完成其第340期内容后，因平台方Changelog的变动宣布停播了！

3. Go Release新特性一览

对于已经过了15个生日的Go来说，其演进的节奏已经非常稳定和成熟了。2024年，Go平稳地发布了两个重要版本：Go 1.22和Go 1.23。下面我们就来简单浏览一下这两个版本的主要新特性。

3.1 Go 1.22主要新特性

语言特性

• loopvar语义修正：for循环中通过短声明定义的循环变量，由整个循环共享一个实例变为每次迭代定义一个实例。这是 Go 语言发展历史上第一次真正的填语义层面的“坑”。
• for range支持整型表达式：for range循环可以遍历整型范围，如for i := range 10。

编译器和运行时

• PGO优化增强：基于PGO的构建可以实现更高比例的调用去虚拟化(devirtualize)，带来性能提升。
• 编译器优化：编译器可以更多地运用devirtualize和inline技术进行优化。
• 运行时优化：运行时可以使基于类型的垃圾收集的元数据更接近每个堆对象，从而降低CPU和内存开销。

工具链

• go work支持vendor：go work命令可以管理vendor目录，并且支持使用go build -mod=vendor构建。
• go mod init改进：不再尝试导入其他vendor工具(比如Gopkg)的配置文件。
• go test -cover改进： 对于没有测试文件的包，会报告覆盖率为0.0%。

标准库

• math/rand/v2: 标准库第一个V2版本包。
• 增强http.ServeMux的表达能力: 新版ServeMux支持静态路由、通配符、主机匹配和变量捕获。

3.2 Go 1.23 主要新特性

语言特性

• 自定义函数迭代器：for range语句支持遍历用户自定义的集合类型，需要定义满足特定签名的迭代器函数。
• 别名中增加泛型参数：支持在类型别名定义中使用类型参数，如：

type MySlice[T any] = []T

编译器与运行时

• PGO构建速度提升: 该版本优化后，PGO带来的编译开销显著降低。
• 限制对linkname的使用: Go 1.23禁止使用linkname指令引用标准库中未标记的内部符号。

工具链

• Telemetry (遥测): go工具链程序收集性能和使用数据的系统，且支持go telemetry on|off|local命令。
• go env -changed: go env子命令增加-changed选项，可以查看当前Go环境中设置的Go环境变量值与默认值有差异的项的值。
• go mod tidy -diff: go mod tidy增加-diff选项，只打印更新信息但不做实际更新。
• go.mod中增加godebug指示符: 可以通过该指示符设置特定的GODEBUG选项。

标准库

• Timer/Ticker变化: Timer和Ticker的GC不再需要Stop方法，Stop/Reset后不再接收旧值。
• structs包: 添加一个零size的类型HostLayout，用于控制编译器对结构体类型的布局方式。
• unique包: 新增了unique包，用于处理唯一值的集合。
• iter包: 新增了iter包，并增加了函数迭代器相关的实用函数到maps、slices等包中。

更多更详细关于Go新特性的内容，请阅读《Go 1.22中值得关注的几个变化》和《Go 1.23中值得关注的几个变化》。

4. 2025展望

按照Go演进的一贯风格，我本不该对Go抱有过多期待^_^，但还是忍不住想说几句。

Go已经稳稳地占据了云计算领域的头部后端编程语言地位，在多个编程语言排行榜上名列前茅，Go社区也在健康快速地发展。然而，机遇与风险总是并存。

虽然Go在云原生、Web服务、微服务、API和CLI开发方面拥有明显优势，但也面临着来自Rust等语言的挑战。Go需要进一步巩固其在这些优势领域的地位，同时探索一些能够发挥自身优势的新方向，例如AI应用开发等。

同时，我们期待新一代Go团队领导者，尤其是来自Go编译器和运行时组的领导者们，能够深入打磨和优化Go语言的编译器、运行时性能以及语言互操作性。毕竟，谁不喜欢那种因性能自然增长而带来的愉悦感，以及借助其他语言优势生态快速完成功能的灵活性呢!

最后，感谢Go团队和Go社区在Go语言演进发展上做出的贡献，希望Go越走越好！

Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时，我们也会加强代码质量和最佳实践的分享，包括如何编写简洁、可读、可测试的Go代码。此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
• Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

本文永久链接 – https://tonybai.com/2024/11/14/go-map-use-swiss-table

在2024月11月5日的Go compiler and runtime meeting notes中，我们注意到了一段重要内容，如下图红框所示：

这表明，来自字节的一位工程师在两年多前提出的“使用Swiss table重新实现Go map”的建议即将落地，目前该issue已经被纳入Go 1.24里程碑。

Swiss Table是由Google工程师于2017年开发的一种高效哈希表实现，旨在优化内存使用和提升性能，解决Google内部代码库中广泛使用的std::unordered_map所面临的性能问题。Google工程师Matt Kulukundis在2017年CppCon大会上详细介绍了他们在Swiss Table上的工作：

目前，Swiss Table已被应用于多种编程语言，包括C++ Abseil库的flat_hash_map(可替换std::unordered_map)、Rust标准库Hashmap的默认实现等。

Swiss Table的出色表现是字节工程师提出这一问题的直接原因。字节跳动作为国内使用Go语言较为广泛的大厂。据issue描述，Go map的CPU消耗约占服务总体开销的4%。其中，map的插入（mapassign）和访问（mapaccess）操作的CPU消耗几乎是1:1。大家可千万不能小看4%这个数字，以字节、Google这样大厂的体量，减少1%也意味着真金白银的大幅节省。

Swiss Table被视为解决这一问题的潜在方案。字节工程师初版实现的基准测试结果显示，与原实现相比，Swiss Table在查询、插入和删除操作上均提升了20%至50%的性能，尤其是在处理大hashmap时表现尤为突出；迭代性能提升了10%；内存使用减少了0%至25%，并且不再消耗额外内存。

这些显著的性能提升引起了Go编译器和运行时团队的关注，特别是当时负责该子团队的Austin Clements。在经过两年多的实验和评估后，Go团队成员Michael Pratt基于Swiss Table实现的internal/runtime/maps最终成为Go map的底层默认实现。

在本文中，我们将简单介绍Swiss Table这一高效的哈希表实现算法，并提前看一下Go map的Swiss Table实现。

在进入swiss table工作原理介绍之前，我们先来回顾一下当前Go map的实现(Go 1.23.x)。

1. Go map的当前实现

map，也称为映射，或字典，或哈希表，是和数组等一样的最常见的数据结构。实现map有两个关键的考量，一个是哈希函数(hash function)，另一个就是碰撞处理(collision handling)。hash函数是数学家的事情，这里不表。对于碰撞处理，在大学数据结构课程中，老师通常会介绍两种常见的处理方案：

• 开放寻址法(Open Addressing)

在发生哈希碰撞时，尝试在哈希表中寻找下一个可用的位置，如下图所示k3与k1的哈希值发生碰撞后，算法会尝试从k1的位置开始向后找到一个空闲的位置：

• 链式哈希法(拉链法, Chaining)

每个哈希桶(bucket)存储一个链表（或其他数据结构），所有哈希值相同的元素(比如k1和k3)都被存储在该链表中。

Go当前的map实现采用的就是链式哈希，当然是经过优化过的了。要了解Go map的实现，关键把握住下面几点：

• 编译器重写

我们在用户层代码中使用的map操作都会被Go编译器重写为对应的runtime的map操作，就如下面Go团队成员Keith Randall在GopherCon大会上讲解map实现原理的一个截图所示：

• 链式哈希

前面提过，Go map当前采用的是链式哈希的实现，一个map在内存中的结构大致如下：

我们看到，一个map Header代表了一个map类型的实例，map header中存储了有关map的元数据(图中字段与当前实现可能有少许差异，毕竟那是几年前的一个片子了)，如：

- len: 当前map中键值对的数量。
- bucket array: 存储数据的bucket数组，可以对比前面的链式哈希的原理图进行理解，不过不同的是，Go map中每个bucket本身就可以存储多个键值对，而不是指向一个键值对的链表。
- hash seed: 用于哈希计算的种子，用于分散数据并提高安全性。

通常一个bucket可以存储8个键值对，这些键值对是根据键的哈希值分配到对应的bucket中。

注：在《Go语言第一课》专栏中，有关于Go map工作原理的系统说明，感兴趣的童鞋可以看看。

• 溢出桶(overflow bucket)

每个bucket后面还会有Overflow Bucket。当一个bucket中的数据超出容量时，会创建overflow bucket来存储多余的数据。这样可以避免直接扩展bucket数组，节省内存空间。但如果出现过多的overflow bucket，性能就会下降。

• “蚂蚁搬家”式的扩容

当map中出现过多overflow bucket而导致性能下降时，我们就要考虑map bucket扩容的事儿了，以始终保证map的操作性能在一个合理的范围。是否扩容由一个名为load factor的参数所控制。load factor是元素数量与bucket数量的比值，比值越高，map的读写性能越差。目前Go map采用了一个经验值来确定是否要扩容，即load factor = 6.5。当load factor超过这个值时，就会触发扩容。所谓扩容就是增大bucket数量(当前实现为增大一倍数量)，减少碰撞，让每个bucket中存放的element数量降下来。

扩容需要对存量element做rehash，在元素数量较多的情况下，“一次性”的完成桶的扩容会造成map操作延迟“突增”，无法满足一些业务场景的要求，因此Go map采用“增量”扩容的方式，即在访问和插入数据时，“蚂蚁搬家”式的做点搬移元素的操作，直到所有元素完成搬移。

Go map的当前实现应该可以适合大多数的场合，但依然有一些性能和延迟敏感的业务场景觉得Go map不够快，另外一个常被诟病的就是当前实现的桶扩容后就不再缩容(shrink)了，这会给内存带来压力。

下面我们再来看看swiss table的结构和工作原理。

2. Swiss table的工作原理

就像前面提到的，Swiss table并非来自某个大学或研究机构的论文，而是来自Google工程师在工程领域的”最佳实践”，因此关于Swiss table的主要资料都来自Google的开源C++ library Abseil以及开发者的演讲视频。在Abseil库中，它是flat_hash_map、flat_hash_set、node_hash_map以及node_hash_set等数据结构的底层实现，并且Swiss table的实现在2018年9月正式开源。

和Go map当前实现不同，Swiss table使用的不是拉链法，而是开放寻址，但并非传统的方案。下面是根据公开资源画出的一个Swiss table的逻辑结构图(注意：并非真实内存布局)：

如果用一个式子来表示Swiss table，我们可以用：

A swiss table = N * (metdata array + slots array)

我们看到：swiss table将所谓的桶（这里叫slot）分为多个group，每个group中有16个slot，这也是swiss table的创新，即将开放寻址方法中的probing(探测key碰撞后下一个可用的位置(slot))放到一个16个slot的group中进行，这样的好处是可以通过一个SIMD指令并行探测16个slot，这种方法也被称为Group Probing。

在上图中，我们看到一个Group由metadata和16个slot组成。metadata中存储的是元数据，而slot中存储的是元素(key和value)。Group probling主要是基于metadata实现的，Google工程师的演讲有对group probing实现的细节描述。

当我们向swiss table插入一个元素或是查找一个元素时，swiss table会通过hash函数对key进行求值，结果是一个8字节(64bit)的数。和Go map的当前实现一样，这个哈希值的不同bit功用不同，下图是一个来自abseil官网的示例：

哈希值的高57bit被称为H1，低7bit被称为H2。前者用于标识该元素在Group内的索引，查找和插入时都需要它。后者将被用于该元素的元数据，放在metadata中存储，用于快速的group probing之用，也被称为哈希指纹。

每个Group的metadata也是一个16字节数组，每个字节对应一个slot，是该slot的控制字节。这个字节的8个bit位的组成如下：

metadata中的控制字节有三个状态：

• 最高位为1，其余全零为空闲状态(Empty)，即对应的slot尚未曾被任何element占据过；
• 最高位为0，后7位为哈希指纹(H2)，为对应的slot当前已经有element占据的已使用状态；
• 最高位为1，其他位为1111110的，为对应的slot为已删除状态，后续可以被继续使用。

下面是Abseil开发者演进slide中的一个针对swiss table的迭代逻辑：

通过这幅图可以看出H1的作用。不过这里通过pos = pos + 1进行probing（探测）显然是不高效的！metadata之所以设计为如此，并保存了插入元素的哈希指纹就是为了实现高效的probing，下图演示了基于key的hash值的H2指纹通过SIMD指令从16个位置中快速得到匹配的pos的过程：

虽然有两个匹配项，但这个过程就像“布隆过滤器”一样，快速排除了不可能的匹配项，减少了不必要的内存访问。

由此也可以看到：swiss table的16个条目的分组大小不是随意选择的，而是基于SSE2寄存器长度(128bit, 16bytes)和现代CPU的缓存行大小(64字节)优化的，保证了一个Group的控制字节能被单次SIMD指令处理。

此外swiss table也是通过load factor来判定是否需要对哈希表进行扩容，一旦扩容，swiss table通常是会将group数量增加一倍，然后重新计算当前所有元素在新groups中的新位置(rehash)，这个过程是有一定开销的。如果不做优化，当表中元素数量较多时，这个过程会导致操作延迟增加。

最后，虽然多数情况是在group内做probing，但当元素插入时，如果当前Group已满，就必须探测到下一个Group，并将元素插入到下一个Group。这样，在该元素的查找操作中，probing也会跨group进行。

到这里，我们已经粗略了解了swiss table的工作原理，那么Go tip对swiss table当前的实现又是怎样的呢？我们下面就来看看。

3. Go tip版本当前的实现

Go tip版本基于swiss table的实现在https://github.com/golang/go/blob/master/src/internal/runtime/maps下。

由于Go map是原生类型，且有了第一版实现，考虑到Go1兼容性，新版基于swiss table的实现也要继承已有的语义约束。同时，也要尽量避免swiss table自身的短板，Go团队在swiss table之上做了局部改进。比如为了将扩容带来的开销降到最低，Go引入了多table的设计，以支持渐进式扩容。也就是说一个map实际上是多个swiss table，而不是像上面说的一个map就是一个swiss table。每个table拥有自己的load factor，可以独立扩容(table的扩容是一次性扩容)，这样就可以将扩容的开销从全部数据变为局部少量数据，减少扩容带来的影响。

Go swiss-table based map的逻辑结构大致如下：

我们可以看出与C++ swisstable的最直观不同之处除了有多个table外，每个group包含8个slot和一个control word，而不是16个slot。此外，Go使用了二次探测(quadratic probing), 探测序列必须以空slot结束。

为了实现渐进式扩容，数据分散在多个table中；单个table容量有上限(maxTableCapacity)，超过上限时分裂成两个table；使用可扩展哈希(extendible hashing)根据hash高位选择table，且每个table可以独立增长。

Go使用Directory管理多个table，Directory是Table的数组，大小为2^globalDepth。如果globalDepth=2，那Directory最多有4个表，分为0×00、0×01、0×10、0×11。Go通过key的hash值的前globalDepth个bit来选择table。这是一种“extendible hashing”，这是一种动态哈希技术，其核心特点是通过动态调整使用的哈希位数(比如上面提到的globalDepth)来实现渐进式扩容。比如：初始可能只用1位哈希值来区分，需要时可以扩展到用2位，再需要时可以扩展到用3位，以此类推。

举个例子，假设我们用二进制表示哈希值的高位，来看一个渐进式扩容的过程：

• 初始状态 (Global Depth = 1):

directory
hash前缀  指向的table
0*** --> table1 (Local Depth = 1)
1*** --> table2 (Local Depth = 1)

• 当table1满了需要分裂时，增加一位哈希值 (Global Depth = 2):

directory
hash前缀  指向的table
00** --> table3 (Local Depth = 2)  // 由table1扩容而成
01** --> table4 (Local Depth = 2)  // 由table1扩容而成
10** --> table2 (Local Depth = 1)
11** --> table2 (Local Depth = 1)  // 复用table2因为它的Local Depth还是1

• 如果table2也满了，需要分裂：

directory
hash前缀  指向的table
00** --> table3 (Local Depth = 2)
01** --> table4 (Local Depth = 2)
10** --> table5 (Local Depth = 2) // 由table2扩容而成
11** --> table6 (Local Depth = 2) // 由table2扩容而成

通过extendible hashing实现的渐进式扩容，每次只处理一部分数据，扩容过程对其他操作影响小，空间利用更灵活。

对于新版go map实现而言，单个Table达到负载因子阈值时触发Table扩容。当需要分裂的Table的localDepth等于map的globalDepth时触发Directory扩容，这就好理解了。

除此之外，Go版本对small map也有特定优化，比如少量元素(<=8)时直接使用单个group，避免或尽量降低swiss table天生在少量元素情况下的性能回退问题。

更多实现细节，大家可以自行阅读https://github.com/golang/go/blob/master/src/internal/runtime/maps/下的Go源码进行理解。

注：目前swiss table版的go map依然还未最终定型，并且后续还会有各种优化加入，这里只是对当前的实现(2024.11.10)做概略介绍，不代表以后的map实现与上述思路完全一致。

4. Benchmark

目前gotip版本中GOEXPERIMENT=swissmap默认已经打开，我们直接用gotip版本即可体验基于swiss table实现的map。

字节工程师zhangyunhao的gomapbench repo提供了对map的性能基准测试代码，不过这个基准测试太多，我大幅简化了一下，只使用Int64，并只测试了元素个数分别为12、256和8192时的情况。

注：我基于Centos 7.9，使用Go 1.23.0和gotip(devel go1.24-84e58c8 linux/amd64)跑的benchmark。

// 在experiments/swiss-table-map/mapbenchmark目录下
$go test -run='^$' -timeout=10h -bench=. -count=10 > origin-map.txt
$GOEXPERIMENT=swissmap gotip test -run='^$' -timeout=10h -bench=. -count=10 > swiss-table-map.txt
$benchstat origin-map.txt swiss-table-map.txt > result.txt

注：gotip版本的安装请参考《Go语言第一课》专栏的第3讲。benchstat安装命令为go install golang.org/x/perf/cmd/benchstat@latest

下面是result.txt中的结果：

goos: linux
goarch: amd64
pkg: demo
cpu: Intel(R) Xeon(R) Platinum
                                  │ origin-map.txt │         swiss-table-map.txt          │
                                  │     sec/op     │    sec/op     vs base                │
MapIter/Int/12-8                      179.7n ± 10%   190.6n ±  4%        ~ (p=0.436 n=10)
MapIter/Int/256-8                     4.328µ ±  5%   3.748µ ±  1%  -13.40% (p=0.000 n=10)
MapIter/Int/8192-8                    137.3µ ±  1%   123.6µ ±  1%   -9.95% (p=0.000 n=10)
MapAccessHit/Int64/12-8               10.12n ±  2%   10.68n ± 14%   +5.64% (p=0.000 n=10)
MapAccessHit/Int64/256-8              10.29n ±  3%   11.29n ±  1%   +9.77% (p=0.000 n=10)
MapAccessHit/Int64/8192-8             25.99n ±  1%   14.93n ±  1%  -42.57% (p=0.000 n=10)
MapAccessMiss/Int64/12-8              12.39n ± 88%   20.99n ± 50%        ~ (p=0.669 n=10)
MapAccessMiss/Int64/256-8             13.12n ±  6%   11.34n ±  7%  -13.56% (p=0.000 n=10)
MapAccessMiss/Int64/8192-8            15.71n ±  1%   14.03n ±  1%  -10.66% (p=0.000 n=10)
MapAssignGrow/Int64/12-8              607.1n ±  2%   622.6n ±  2%   +2.54% (p=0.000 n=10)
MapAssignGrow/Int64/256-8             25.98µ ±  3%   23.22µ ±  1%  -10.64% (p=0.000 n=10)
MapAssignGrow/Int64/8192-8            792.3µ ±  1%   844.1µ ±  1%   +6.54% (p=0.000 n=10)
MapAssignPreAllocate/Int64/12-8       450.2n ±  2%   409.2n ±  1%   -9.11% (p=0.000 n=10)
MapAssignPreAllocate/Int64/256-8     10.412µ ±  1%   6.055µ ±  2%  -41.84% (p=0.000 n=10)
MapAssignPreAllocate/Int64/8192-8     342.4µ ±  1%   232.6µ ±  2%  -32.05% (p=0.000 n=10)
MapAssignReuse/Int64/12-8             374.2n ±  1%   235.4n ±  2%  -37.07% (p=0.000 n=10)
MapAssignReuse/Int64/256-8            8.737µ ±  1%   4.716µ ±  4%  -46.03% (p=0.000 n=10)
MapAssignReuse/Int64/8192-8           296.4µ ±  1%   181.0µ ±  1%  -38.93% (p=0.000 n=10)
geomean                               1.159µ         984.2n        -15.11%

我们看到了除了少数测试项有不足外(比如MapAssignGrow以及一些元素数量少的情况下)，大多数测试项中，新版基于swiss table的map的性能都有大幅提升，有些甚至接近50%！

5. 小结

本文探讨了Go语言中的map实现的重塑，即引入Swiss Table这一高效哈希表结构的背景与优势。Swiss Table由Google工程师开发，旨在优化内存使用和提升性能，解决了传统哈希表在高负载情况下的性能瓶颈。通过对比现有的链式哈希实现，Swiss Table展示了在查询、插入和删除操作上显著提高的性能，尤其是在处理大规模数据时。

经过两年多的实验与评估，Go团队决定将Swiss Table作为Go map的底层实现，预计将在Go 1.24中正式落地。新的实现不仅承继了原有的语义约束，还通过引入多表和渐进式扩容的设计，进一步优化了扩容过程的性能。尽管当前实现仍在完善中，但Swiss Table的引入无疑为Go语言的性能提升提供了新的可能性，并为未来进一步优化奠定了基础。

对于那些因Go引入自定义iterator而批评Go团队的Gopher来说，这个Go map的重塑无疑会很对他们的胃口。

本文涉及的源码可以在这里下载。

6. 参考资料

• runtime: use SwissTable – https://github.com/golang/go/issues/54766
• swiss table benchmark result – https://gist.github.com/aclements/9fb32ac0a287d2ff360f1bc166cdf4b8
• Swisstable, a Quick and Dirty Description – https://faultlore.com/blah/hashbrown-tldr/
• Swiss Tables Design Notes – https://abseil.io/about/design/swisstables
• Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step – https://www.youtube.com/watch?v=ncHmEUmJZf4
• Abseil’s Open Source Hashtables: 2 Years In – https://www.youtube.com/watch?v=JZE3_0qvrMg
• Swiss Tables and absl::Hash – https://abseil.io/blog/20180927-swisstables
• SwissMap: A smaller, faster Golang Hash Table – https://www.dolthub.com/blog/2023-03-28-swiss-map/
• What is a Hash Map? – https://www.freecodecamp.org/news/what-is-a-hash-map/
• Inside the Map Implementation – https://www.youtube.com/watch?v=Tl7mi9QmLns

Gopher部落知识星球在2024年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。同时，我们也会加强代码质量和最佳实践的分享，包括如何编写简洁、可读、可测试的Go代码。此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：

• 微博(暂不可用)：https://weibo.com/bigwhite20xx
• 微博2：https://weibo.com/u/6484441286
• 博客：tonybai.com
• github: https://github.com/bigwhite
• Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
• Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。