golang 中 map 的并发问题

[ksedz]

golang 中的 map 并发访问会报错，一般建议是使用读写锁。

我有两个场景不太适合使用读写锁，求问有什么好的解决方案：

1. 并发写入不同的 key，读取和写入肯定不会同时进行
实际场景是每个协程维护一个会话信息，会话之间肯定不会冲突，会话内也不会并发读写。协程内的局部变量可以解决这个问题，但我想汇总协程内的信息，就需要使用 map 了。

2. 大量的并发写入，少量的读取
这个和上面是同一个业务，要对不同会话内的不同类型事件次数进行统计，然后定时打印到控制台。说这是少量的读取也不太合适，因为写入前还要查询原值，但也不是读写锁更适合的读多写少的情况。这里可能是 map 实现本身的问题了，求问有什么更优的数据结构或算法处理这一问题，可以做到高效的原子性的 increase 1 ？

[abbycin]

换 tbb

[ksedz]

@abbycin 谢谢提示。搜了下，是 C++的方案？改动有点大，我先找找其他解决方案。

[jingniao]

map 的 value 弄成结构体指针？

[qianlv7]

分桶，每个桶单独加锁

[teawithlife]

可以换自带的 sync.Map
唯一坑的地方是没有 Len()方法，也就是说如果你需要获取 Map 中的元素个数，得自己遍历一遍数个数。不过看你的使用场景，应该不需要 Len()方法

[foam]

第 2 个场景不要加锁了，太重。用 atomic 包的 cas，其实就是乐观锁。加上 for 重试，保证写入。

[fiypig]

sync.Map

[fighterlyt]

看来上边的人都没找到的具体的问题，map 不支持并发读写的根本原因是** 使用一个有空间大小的结构表示一个无限大小的结构**。这样必然伴随着内存的重新分配和对应的复制问题。所以不管读写是否为同一个 key，总是需要加锁。针对第二个问题，两个 map 就 ok 了，可以用同一把锁,1 个 map[string]***，1 个 map[string]int64

[wysnylc]

对着 java concurrenthashmap 实现一遍

[dongisking]

golang 并发访问会报错？

[zhs227]

@dongisking 准确的说是会 panic，程序直接退出。 一般用 sync.map 或者是加锁。

[reus]

sync.Map 就是为这种场景定制的


The Map type is specialized. Most code should use a plain Go map instead,
with separate locking or coordination, for better type safety and to make it
easier to maintain other invariants along with the map content.

The Map type is optimized for two common use cases: (1) when the entry for a
given key is only ever written once but read many times, as in caches that
only grow, or (2) when multiple goroutines read, write, and overwrite
entries for disjoint sets of keys. In these two cases, use of a Map may
significantly reduce lock contention compared to a Go map paired with a
separate Mutex or RWMutex.

[keepeye]

1. 用 sync.Map
2. 用第三方封装过的 map，分 bucket 的，但还是加锁的思路
3. 自己封装一层，通过 channel 的去限制并发读写 map

[dafsic]

给你看看我用的方法，不说多好，反正我一直这样用 https://www.v2ex.com/t/596606#reply18