golang遍历处理map时的常见性能陷阱

最近一直在重构优化老系统，所以性能优化相关的文章会比较多。
这次的是有关循环处理map时的性能优化。预分配内存之类的大家都知道的就不多说了，今天来讲点大伙不知道的。
要讲的一共有三点，而且都和循环处理map有关。
不要用for-range循环清空map

这里要讨论的“清空”是指删除map中所有键值对，但保留map里已分配的内存供下次复用。
如果只是想释放map并且不再需要复用，那么map1 = nil或者map2 = map[T]U{}就足够了。
内置函数delete可以帮我们实现删除键值对但保留它们在map中的内存空间，通常我们会这么写：

1. for key := range Map1 {
2.     delete(Map1, key)
3. }

复制代码

这种模式化的代码太常见，以至于go编译器专门对其做了优化，只要形式上符合上述代码片段的，编译器都会把循环优化成runtime.mapclear(Map1)，使用runtime内置的map清理函数将map清空，这比靠循环遍历删除要快很多倍。
看到这里你可能会说这不是挺好吗，为什么不让用了呢？
因为现在有更好的替代方案了——内置函数clear。
clear应用在map上时本身就会调用runtime.mapclear(...)，在性能上和循环方法大致一样而且只快不慢。因为两者最终生成代码差不多，性能测试也就没多大意义了，所以这里不做性能测试。
clear还有另一个好处，它更容易让包含它的函数被内联。
这是什么意思呢？go的编译器实际上在编译时要分很多个步骤，粗略地讲go代码在真正开始生成机器码之前，得先经过内联 -> 逃逸分析 -> 语法树改写这样几个阶段。上文说的for循环删除优化在语法树改写这个阶段完成。
这就带来了一个问题，相比一个简单的clear函数调用，编译器认为for循环这种操作更“重量级”，一个函数拥有的“重”操作越多，那么这个函数被内联优化的可能性就越小。
我们看个例子：

1. func RangeClearMap() {
2.         for k := range bigMap {
3.                 delete(bigMap, k)
4.         }
5.         for k := range bigPtrMap {
6.                 delete(bigPtrMap, k)
7.         }
8.         for k := range smallMap {
9.                 delete(smallMap, k)
10.         }
11.         for k := range smallPtrMap {
12.                 delete(smallPtrMap, k)
13.         }
14.         for k := range bigMapIntKey {
15.                 delete(bigMapIntKey, k)
16.         }
17.         for k := range bigPtrMapIntKey {
18.                 delete(bigPtrMapIntKey, k)
19.         }
20.         for k := range smallMapIntKey {
21.                 delete(smallMapIntKey, k)
22.         }
23.         for k := range smallPtrMapIntKey {
24.                 delete(smallPtrMapIntKey, k)
25.         }
26. }
28. func BuiltinClearMap() {
29.         clear(bigMap)
30.         clear(bigPtrMap)
31.         clear(smallMap)
32.         clear(smallPtrMap)
33.         clear(bigMapIntKey)
34.         clear(bigPtrMapIntKey)
35.         clear(smallMapIntKey)
36.         clear(smallPtrMapIntKey)
37. }

复制代码

同样是清空8个map，一个用循环，一个用内置函数。我们看下内联分析的结果：

其中cost就是衡量一个函数里的操作有多“重”的数值标准，超过一定的cost，函数就无法内联。可以看到，使用循环会比使用clear内置函数重整整四倍。虽然最后因为两个函数都很简单所以被内联展开，但碰上更复制一点的函数，显然使用clear能有更多的冗余。
尽管编译器最终会把两者优化成一样的对runtime的map清理函数的调用，但对for循环的优化在内联处理之后，因此for不仅让代码更长，也更容易错失内联优化的机会，而失去内联优化进而会影响逃逸分析从而损失更多性能，你可以在我以前的博客里看到内联和逃逸分析对内联的影响。
clear()是go1.21添加的，因此只要你在用的go版本大于等于1.21，我推荐你尽量使用clear而不是for-range循环来清空map。
遍历访问map时的陷阱

遍历处理map中的元素也是常见操作，不过不像循环删除，编译器在这种代码上并没有什么优化。
最常见的写法是这样的：

1. for key, value := range Map1 {
2.     func1(key, value)
3.     func2(key, value)
4. }

复制代码

这时候，一部分开发者会觉得每次循环都得复制一次value，尤其是1.22开始循环变量每轮都是新变量，这种操作是不是会很慢也很占用内存？毕竟在遍历slice的时候确实有这些问题，那么能不能采用优化slice遍历的相同方法来优化map遍历呢：

1. for key := range Map1 {
2.     func1(key, Map1[key])
3.     func2(key, Map1[key])
4. }

复制代码

现在不用复制value了，性能应该获得提升了吧？真的是这样吗？
我说过很多次，性能优化不能靠想象，要靠benchmark来说话，所以我们来做个性能测试。
我们测试大value和小value在两种循环下的表现，另外还会额外测试一下map里存放指针的情况，测试用的value类型主要是下面两种：

1. // 128字节
2. type BigObject struct {
3.         n1, n2, n3, n4, n5, n6, n7, n8, n9, n10 int64
4.         s1, s2, s3                              string
5. }
7. // 32字节
8. type SmallObject struct {
9.         n1, n2 int64
10.         s1     string
11. }

复制代码

我们一共分8种case进行测试：

1. var (
2.         bigMap            = map[string]BigObject{}
3.         bigPtrMap         = map[string]*BigObject{}
4.         smallMap          = map[string]SmallObject{}
5.         smallPtrMap       = map[string]*SmallObject{}
6. )
8. func init() {
9.         for i := range int64(100) {
10.                 strKey := fmt.Sprintf("Key:%03d", i)
11.                 bigMap[strKey] = NewBigObject()
12.                 bigPtrMap[strKey] = NewBigObjectPtr()
13.                 smallMap[strKey] = NewSmallObject()
14.                 smallPtrMap[strKey] = NewSmallObjectPtr()
15.         }
16. }

复制代码

每个map里都填充100个元素，元素的值随机生成，不过我限制了字符串都是等长的，这是为了结果的准确性。
测试也比较简单：

1. func BenchmarkBigObjectLoopCopy(b *testing.B) {
2.         for b.Loop() {
3.                 for _, v := range bigMap {
4.                         if v.n1 == 0 || v.n2 == 0 {
5.                                 panic("error")
6.                         }
7.                 }
8.         }
9. }
11. func BenchmarkBigObjectPtrLoopCopy(b *testing.B) {
12.         for b.Loop() {
13.                 for _, v := range bigPtrMap {
14.                         if v.n1 == 0 || v.n2 == 0 {
15.                                 panic("error")
16.                         }
17.                 }
18.         }
19. }
21. func BenchmarkBigObjectLoopKey(b *testing.B) {
22.         for b.Loop() {
23.                 for k := range bigMap {
24.                         if bigMap[k].n1 == 0 || bigMap[k].n2 == 0 {
25.                                 panic("error")
26.                         }
27.                 }
28.         }
29. }
31. func BenchmarkBigObjectPtrLoopKey(b *testing.B) {
32.         for b.Loop() {
33.                 for k := range bigPtrMap {
34.                         if bigPtrMap[k].n1 == 0 || bigPtrMap[k].n2 == 0 {
35.                                 panic("error")
36.                         }
37.                 }
38.         }
39. }
41. func BenchmarkSmallObjectLoopCopy(b *testing.B) {
42.         for b.Loop() {
43.                 for _, v := range smallMap {
44.                         if v.n1 == 0 || v.n2 == 0 {
45.                                 panic("error")
46.                         }
47.                 }
48.         }
49. }
51. func BenchmarkSmallObjectPtrLoopCopy(b *testing.B) {
52.         for b.Loop() {
53.                 for _, v := range smallPtrMap {
54.                         if v.n1 == 0 || v.n2 == 0 {
55.                                 panic("error")
56.                         }
57.                 }
58.         }
59. }
61. func BenchmarkSmallObjectLoopKey(b *testing.B) {
62.         for b.Loop() {
63.                 for k := range smallMap {
64.                         if smallMap[k].n1 == 0 || smallMap[k].n2 == 0 {
65.                                 panic("error")
66.                         }
67.                 }
68.         }
69. }
71. func BenchmarkSmallObjectPtrLoopKey(b *testing.B) {
72.         for b.Loop() {
73.                 for k := range smallPtrMap {
74.                         if smallPtrMap[k].n1 == 0 || smallPtrMap[k].n2 == 0 {
75.                                 panic("error")
76.                         }
77.                 }
78.         }
79. }

复制代码

8种case就是大value的map和小value的分别用k,v := range map遍历和只用key遍历，看看性能差异。

结果很是让人诧异，自认为的不需要复制value所以访问更快的结论是错的，而且错的离谱：复制value的做法性能是只用key遍历的3倍！
为啥会这样呢？因为你掉进hashmap的陷阱里了，我就直接说原因了：

• 以for k,v := range m遍历map时，键值对是被顺序访问的，这对缓存命中和cpu的模式预测更友好，性能会比用key进行hash的随机访问要好；
  
• 使用m[k]访问时需要计算key的hash，这一步是比较耗费计算资源的，哪怕新版本换了swissmap之后也一样，而for-range循环不需要计算hash值。hash计算对性能的影响可以看我这篇博客讲解。
  

这两点就是hashmap的陷阱，本来在少量多次或者随机查找等模式下算不上太大的问题，但在循环遍历的情形下影响就会放大，最后导致出现3倍以上的性能差异。
所以当你要遍历处理每一个value的时候，最好用for k,v := range m或者for _,v := range m。
不过也有例外：如果你的value比较大，你需要遍历key，符合过滤条件的key的value才需要处理，这种时候那些无用的复制就会成为性能绊脚石了。不过还是老话，先做benchmark再谈优化。
复制map时的性能陷阱

最后一个性能陷阱埋在复制map时。
这里说的“复制”是浅复制，把键值对复制到一个新map里去，里面的指针或者slice都是浅拷贝的。
还是先上常见写法，实际上在1.21之前你也只能这么写：

1. m2 := make(map[T]U, len(m1))
2. for k, v := range m1 {
3.     m2[k] = v
4. }

复制代码

编译器同样也不会对这种代码有特殊优化，循环会老老实实地执行。
到了1.21，我们可以用maps.Clone做一样的事情，而且这个标准库函数也会在底层调用runtime里的专用map复制函数，性能杠杠的。
我们准备一下性能测试，map样本沿用上一节里的：

1. func BenchmarkMapClone(b *testing.B) {
2.         b.Run("range-smallMap", func(b *testing.B) {
3.                 for b.Loop() {
4.                         m := make(map[string]SmallObject, len(smallMap))
5.                         for k, v := range smallMap {
6.                                 m[k] = v
7.                         }
8.                 }
9.         })
10.         b.Run("range-smallPtrMap", func(b *testing.B) {
11.                 for b.Loop() {
12.                         m := make(map[string]*SmallObject, len(smallPtrMap))
13.                         for k, v := range smallPtrMap {
14.                                 m[k] = v
15.                         }
16.                 }
17.         })
18.         b.Run("range-bigMap", func(b *testing.B) {
19.                 for b.Loop() {
20.                         m := make(map[string]BigObject, len(bigMap))
21.                         for k, v := range bigMap {
22.                                 m[k] = v
23.                         }
24.                 }
25.         })
26.         b.Run("range-bigPtrMap", func(b *testing.B) {
27.                 for b.Loop() {
28.                         m := make(map[string]*BigObject, len(bigPtrMap))
29.                         for k, v := range bigPtrMap {
30.                                 m[k] = v
31.                         }
32.                 }
33.         })
34.         b.Run("clone-smallMap", func(b *testing.B) {
35.                 for b.Loop() {
36.                         maps.Clone(smallMap)
37.                 }
38.         })
39.         b.Run("clone-smallPtrMap", func(b *testing.B) {
40.                 for b.Loop() {
41.                         maps.Clone(smallPtrMap)
42.                 }
43.         })
44.         b.Run("clone-bigMap", func(b *testing.B) {
45.                 for b.Loop() {
46.                         maps.Clone(bigMap)
47.                 }
48.         })
49.         b.Run("clone-bigPtrMap", func(b *testing.B) {
50.                 for b.Loop() {
51.                         maps.Clone(bigPtrMap)
52.                 }
53.         })
54. }

复制代码

在这里如果你用的go版本是1.24，那么你会踩到第一个陷阱，对没错，我说了有三种陷阱，没说只有三个哦。
1.24的maps.clone实现有问题，会有严重的性能回退，所以你可以看到它和循环复制性能没有差距，甚至有时候还更慢一点：

具体是什么样的问题我就不深入讲解了，因为是偷懒导致的很无聊的问题。好在这个问题会在1.25修复，修复代码已经在主分支上了，因此我们可以用go version go1.25-devel_3fd729b2a1 Sat May 24 08:48:53 2025 -0700 windows/amd64来测试：

修复后结果就和1.22以及1.23一样了。总得来说maps.Clone虽然多浪费了一点内存，但速度是循环复制的1.5~3倍。
所以要复制map的时候，尽量去用maps.Clone，这样就能避开循环复制慢这第二个陷阱。
总结

golang果然还是那个golang，大道至简的外皮下往往暗藏杀机。
真要说什么原则的话，那就是如果有对应的标准库函数/内置函数，那就用，尽量少在map上直接用循环。
还有我说过无数次的，性能优化要靠benchmark，切记不要依赖经验去预判，陷阱二就是我用benchmark找出来的“预判”失误。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！