本文永久链接 – 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

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

本文永久链接 – https://tonybai.com/2024/10/24/cognitive-load-impact-on-programming-language-choice-and-study

在《Go语言精进之路：从新手到高手的编程思想、方法和技巧》两卷书出版后，我收到了一些读者的反馈。其中一位读者提到：“为什么作者如此偏爱使用心智负担这个词？”当时我对此并未给予太多关注。然而，近期我阅读了一些关于认知心理学和脑科学的著作后，才意识到读者的反馈不仅仅是对该词频繁使用的关注，更可能暗示了用词不当的问题。

“心智负担”（Mental Load）指的是在处理多任务或日常生活安排时所需耗费的心理资源和精力，包括记忆、计划、组织以及应对各种任务所带来的精神压力。然而，在学习、思考和理解的情境中，特别是在编程语言的学习中，使用“认知负荷”（Cognitive Load）这一术语可能更为恰当。

认知负荷理论最初由澳大利亚新南威尔士大学的认知心理学家约翰·斯威勒(John Sweller)于1988年首先提出来的，旨在解释学习过程中的认知资源分配。认知负荷是指在学习、思考或解决问题时，大脑在处理信息和执行任务时所承受的负担。在选择编程语言时，认知负荷是一个至关重要的因素，指的是人们在学习和使用某种编程语言时，为理解语法、掌握工具和解决问题所需付出的心理负担和精力。

那么，在面对众多主流编程语言时，在不考虑市场需求与公司或组织强制学习的情况下，认知负荷究竟如何影响开发人员对编程语言的选择呢？在这篇文章中，我将进行一些不那么严谨，也非专业的粗略探讨，希望能够为大家带来一些启发。

1. 认知负荷在编程语言中的体现

认知负荷理论发展到今天，其总体被分为三种类型：

• 内在认知负荷(Intrinsic Cognitive Load)

内在认知负荷，也称为固有负荷，是由学习材料本身的复杂性所决定的，它与学习任务的本质和内容密切相关。例如，编程语言的语法规则、数据类型、内存管理和并发模型等都是内在负荷的一部分。学习这些概念的难易程度主要取决于编程语言本身的设计和复杂度。

• 外在认知负荷(Extraneous Cognitive Load)

外在负荷是由学习环境和教学方式引起的负担，通常是由于无关信息或低效的学习方法造成的。比如，配置开发环境、学习非必要的工具或被复杂的IDE界面困扰，都可能增加外在负荷。在编程语言学习中，清晰的文档和易于理解的教程可以显著减少外在负荷。

虽然外在负荷不是由编程语言语法本身决定的，但它会影响新手的学习体验。如果学习资源和工具太复杂或不直观，即使是简单的编程语言也会让人感到困难。

• 相关认知负荷(Germane Cognitive Load)

相关认知负荷是指学习过程中专门用于理解、整合和构建知识结构的认知努力。它与思维加工、模式识别、知识内化等过程有关。在编程中，相关认知负荷指的是学习者在掌握编程思想、设计模式和编程习惯时所付出的努力。例如，理解如何在实际项目中应用编程概念，如何优化代码设计，以及如何解决编程中的复杂问题，这些过程都会增加相关认知负荷。这种负担是积极的，因为它有助于深入理解和长期记忆。

下面这张图来自网络，可以帮助我们进一步理解三类认知负荷(只是出发点来自教学角度)：

由此可见，对于新手来说，学习一门编程语言时，外在认知负荷是第一道门槛，它决定了是否能坚持学习，还是选择“Hello and Bye”；内在认知负荷则是基础，是核心；相关认知负荷则是进阶挑战，决定了可以达到的高度。

接下来，我们将针对一些主流编程语言，沿着新手入门学习编程语言的认知负荷先后顺序进行粗略对比。希望这能为大家提供在编程语言选择方面的有用信息，同时帮助不同阶段的学习者针对各自的认知负荷水平做好心理准备。

2. 主流编程语言的认知负荷对比

在探讨主流编程语言的认知负荷时，我们需要从外在认知负荷、内在认知负荷以及相关认知负荷这三个维度进行深入分析。这种分析不仅能帮助我们理解不同语言的特点，更能为选择合适的编程语言提供参考依据。

注：笔者是后端程序员出身，对前端语言比如Javascript、Typescript等了解有限，因此这里将使用像Go、Rust、C++等主流后端语言作为分析和对比的参考对象。

2.1 外在认知负荷的影响

在编程语言学习的初始阶段，外在认知负荷往往是最先遇到的挑战。

Python在这方面表现出色，它简单的环境搭建流程让初学者能够快速开始编程之旅。只需安装一个解释器，新手就能立即开始编写代码。虽然在使用pip管理依赖时可能遇到一些包冲突的问题，但整体来说，在环境搭建、工具使用等外在认知负荷方面对初学者相当友好。

Go语言同样提供了令人称道的开发体验。它的工具链安装过程直观明了，跨平台支持也十分完善。特别值得一提的是，自从Go 1.11引入go modules以来，依赖管理变得更加自动化和直观。虽然对新手来说，理解版本控制可能需要一些时间。此外，Go团队也给出了Go项目布局的官方建议，为开发者进行代码组织提供了清晰的参考。

相比之下，C++的环境搭建则显得较为复杂。开发者需要安装编译器，配置IDE，这些步骤对新手来说都构成了不小的挑战。加上缺乏统一的包管理工具（尽管vcpkg和conan等工具正在改变这一现状），以及灵活但缺乏标准的项目结构，都让C++的外在认知负荷明显高于其他语言。

Rust通过其官方工具链安装工具rustup提供了相对简便的环境搭建方式。它的Cargo包管理器集成度高，使用便捷，而且项目结构的标准化程度高，这些特点都有效降低了外在认知负荷。

Java则介于两个极端之间。它需要安装JDK并配置环境变量(如JAVA_HOME、CLASS_PATH等)，这个过程对新手来说可能有些繁琐。虽然Maven和Gradle这样的依赖管理工具功能强大，但学习曲线较陡峭。不过，Java严格的项目布局规范在初期可能显得死板，但从长远来看反而有助于培养良好的工程习惯。

过了环境安装、工具使用和项目布局这些“外在认知负荷”的关卡后，语言自身的复杂性便会成为新手面前的更大的挑战。

2.2 内在认知负荷考量

谈到语言本身的复杂性，Python的设计理念“简单胜于复杂”使其成为认知负荷最低的选择之一。它的语法接近自然语言，几乎不需要特别的学习就能读懂基本的代码结构。这种简洁性使得Python特别适合编程初学者，以至于主流的儿童编程教学大多使用Python(当然一些启蒙教学使用的是scratch)。

Go语言同样以简洁著称，它的语法设计注重一致性和可读性。虽然保留了指针这样的底层特性，可能会让某些初学者感到困惑，但整体而言，Go的学习曲线相当平缓。值得注意的是，Go 1.18引入泛型后，虽然提升了语言的表达能力，但也增加了一定的复杂性。至于Go是否适合作为从零开始编程的新手，也是见仁见智。

C++的内在认知负荷则明显较高。它支持多种编程范式，包括面向过程、面向对象、模板编程等，这些范式和特性固然强大，但对初学者来说往往构成了较大的认知负担。特别是在处理多态、模板元编程等高级特性时，学习曲线会变得异常陡峭。

Rust的内在认知负荷同样不低，但事实证明其复杂性是有意义的。它的所有权系统和借用检查器虽然增加了学习难度，但这些机制对于理解系统编程的本质非常有帮助，同时提高了程序在运行时的安全性。新手在最初接触这些概念时可能会感到困惑，但掌握后会对内存安全有深刻的理解。

Java的内在认知负荷介于中等水平。它的面向对象语法虽然比Python或Go略显繁琐，但整体而言还算直观。Java的复杂性主要体现在面向对象设计模式、泛型和异常处理等特性上，这些概念需要时间来消化和掌握。

2.3 相关认知负荷的深入分析

在实际应用知识解决问题时，各种语言呈现出不同的特点。

Python的优势在于它能让学习者快速将知识付诸实践。其丰富的标准库和生态、简洁的语法使得从学习到应用的过程异常顺畅。无论是数据科学还是Web开发，Python都能让新手快速看到成果。它支持多种编程范式，并且社区的PEP 8规范为代码风格提供了清晰的指导。

Go语言在知识应用方面同样表现出色。它的工具链完善，容易将所学付诸实践。特别是在服务器端开发领域，Go的并发模型和简洁的语法让新手能够相对轻松地构建高效的后端服务。虽然Go不像传统的面向对象语言那样依赖继承体系，但其接口机制和组合方式为代码设计提供了优雅的解决方案。

C++的相关认知负荷较高，主要体现在将理论知识转化为实践时面临的挑战。内存管理和性能优化这些概念需要大量实践才能真正掌握。它支持多种编程范式，这种灵活性虽然强大，但对初学者来说往往是一把双刃剑。由于缺乏统一的编码规范，新手可能在选择最佳实践时感到困惑。

Rust在这方面呈现出独特的特点。它的所有权系统要求开发者在实践中深入思考内存管理问题，这个过程虽然充满挑战，但却能培养扎实的系统编程思维。Rust社区提供的编码规范和工具链都很完善，有助于形成良好的编程习惯。

Java则以其企业级开发的特点著称。它要求开发者深入理解面向对象编程的核心概念，这个过程需要较长时间的积累。Java的设计模式体系完备，社区的编码规范成熟，这些特点有助于培养专业的工程思维，但对新手来说可能需要更多的时间和耐心。

2.4 综合评估

通过以上分析，我们可以看出不同语言在认知负荷方面的特点。

Python以其全方位的低认知负荷成为初学者的理想选择。

Go语言通过简洁的设计和完善的工具链在降低认知负荷方面做出了显著成效。

Java虽然相对繁琐，但其成熟的生态系统和规范的开发流程为长期发展提供了良好基础。

Rust和C++的学习曲线较陡，但它们在系统编程和性能优化方面的深度让投入的学习成本变得有价值。

在理解了编程语言的认知负荷特点后，我们不妨再从心理学的角度，特别是借助三脑理论的视角，来探讨初学者是如何在面对不同编程语言时做出选择的。

3. 初学者的编程语言学习决策过程

三脑理论(Triune Brain Theory)由Paul D. MacLean于1970年提出的理论假说，该理论将人脑分为三个层次，如下图所示：

• 爬虫脑（Reptilian Brain）：也称原始脑，负责基本生存反应，包括对威胁的快速反应和本能行为。
• 情绪脑（Limbic System）：处理情绪和动机，影响记忆形成和社交行为。
• 理性脑（Neocortex）：负责高级认知功能，如逻辑思考、语言处理和复杂决策。

注：三脑理论提出较早，如今有新的理论认为三脑理论毫无依据。不过这里我们假定这个理论是正确和适用的。

三脑理论影响初学者的编程学习决策的过程是怎样的呢？这个过程往往涉及本能反应(爬虫脑主导)、情感体验（情绪脑主导）和理性思考(理性脑主导)三个层面的互动。我们继续往下看。

3.1 初学阶段的决策历程

在首次接触编程语言时，学习者的反应往往是多层次的。本能层面的反应最为直接，面对像C++这样认知负荷较高的语言时，很多人会本能地产生畏惧感。这种反应不是简单的怯懦，而是大脑对复杂性的自然防御机制。相反，Python这类认知负荷较低的语言则较少触发这种应激反应，使得学习者能够保持相对轻松的心态。

情感层面的体验则更为复杂。当成功运行第一个程序时，无论使用什么语言，都会带来成就感。但随着学习的深入，不同语言带来的情感体验会产生分化。举个例子，我在早期学习Java时，仅仅是配置环境变量这样的基础工作就带来了挫折感，这种负面情绪很容易影响学习的积极性。而Rust虽然入门门槛较低，但一旦进入到所有权系统的学习，很多人会因为频繁的编译错误而感到沮丧。

理性思考则是决策过程中最后但也是最重要的环节。这包括对语言应用领域的评估、职业发展前景的考虑，以及个人学习时间和精力投入的权衡。这个阶段的决策通常更加慎重，也更具有长期性。

3.2 深入学习阶段的转变

随着学习的深入，最初的决策依据往往会发生改变。原本令人望而生畏的特性可能转变为吸引力的来源。这种转变在Rust的学习过程中特别明显，当开发者逐渐理解了所有权系统的价值，最初的困惑可能转化为对语言设计的欣赏。

在这个阶段，情感体验也往往变得更加丰富。克服困难带来的成就感可能超越了简单的编程快感，这也解释了为什么一些看似“难学”的语言反而能够培养出更加忠实的用户群体。Rust连续多年在最受欢迎编程语言榜单上位居前列，很大程度上就源于这种深层的技术认同感。

理性思考在这个阶段会更加全面，不再局限于语言本身的特性，而是扩展到整个技术生态系统的考量。开发者会更多地思考语言的性能特点、社区活跃度、工具链完善程度等因素。

3.3 认知负荷与学习效果

从短期来看，低认知负荷的语言确实能够提供更平缓的学习曲线，让入门过程更加顺畅。Python和Go在这方面的优势明显，它们能让学习者快速进入实践阶段，建立信心。但这种便利性有时也会带来一个意想不到的问题：学习者可能在掌握了基础语法后陷入平台期，难以实现质的突破。这也是为什么经常有读者询问如何才能在Go语言编程中更进一步。

相比之下，高认知负荷的语言虽然入门较难，但往往能够培养更深入的编程思维。比如Rust的所有权系统，虽然增加了学习难度，但这种设计迫使开发者深入思考内存管理的问题，从而建立更扎实的系统编程基础。C++的模板元编程虽然复杂，但掌握后能够大大提升代码的抽象能力和复用效率。

不过，我们也要警惕过高的认知负荷带来的风险。如果学习过程中的挫折感持续累积，很容易导致半途而废。每年入门一次Rust的真实案例也屡见不鲜。这就要求我们在选择编程语言时，既要考虑个人的学习能力和时间投入，也要权衡职业发展的需求，找到一个适合自己的平衡点。

4. 小结

在探讨了认知负荷对编程语言学习的影响后，我们可以得出一些粗浅的见解：编程语言的学习绝非简单的语法掌握过程，而是一个涉及多个认知维度的复杂历程。从开发环境的搭建到语言特性的理解，从基础概念的掌握到工程实践的应用，每个阶段都会给学习者带来不同程度的认知压力。理解这些认知负荷的本质，有助于我们做出更明智的编程语言学习的选择。

对于编程新手来说，像Python和Go这样在各个维度都尽量降低认知负荷的语言，无疑是入门的理想选择。但我们也要认识到，较高的认知负荷未必就是缺点。就像Rust和C++这样的语言，它们的学习曲线虽然陡峭，但这种”困难”往往蕴含着宝贵的学习机会。通过克服这些认知挑战，开发者能够建立起更深入的系统编程认知，形成更扎实的技术功底。

选择合适的编程语言，某种程度上就像选择一位长期相处的伙伴。这个选择不仅要考虑语言本身的特点，还要权衡个人的学习能力、职业规划和时间投入。认知负荷理论为我们提供了一个有价值的分析框架，但最终的选择还是要回归到个人的实际需求和发展目标。正如没有完美的编程语言一样，也没有放之四海而皆准的学习路径。找到适合自己的平衡点，或许才是最务实的学习策略。

最后，在人工智能编码辅助技术飞速发展的今天，开放的学习心态和持续学习的能力，可能比选择某个特定的编程语言更为重要。毕竟唯一不变的可能就是变化本身。

5. 参考资料

• 《思考，快与慢》- https://book.douban.com/subject/10785583/
• 《认知觉醒》 – https://book.douban.com/subject/35193035/

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

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