Golang Go语言为什么不支持并发读写 map?

发布于 1周前 作者 bupafengyu 来自 Go语言

大家好,我是 frank ,「 Golang 语言开发栈」公众号作者。

01 介绍

在 Go 语言项目开发中,我们经常会使用哈希表 map,它的时间复杂度是 O(1),Go 语言中的 map 使用开放寻址法避免哈希碰撞。

Go 语言中的 map 并非原子操作,不支持并发读写操作。

Go 官方认为 map 在大多数情况下是使用 map 进行并发读操作,仅在少数情况下是使用 map 进行并发读写操作。

如果 Go 语言中的 map 原生支持并发读写操作,在操作时需要先获取互斥锁,反而会降低只有并发读操作时的性能。

在需要并发读写操作 map 时,可以结合 sync 包中的互斥锁一起使用。

02 并发读写 map

Go 支持并发读 map,不支持并发读写 map

示例代码:

func main() {
	var m = make(map[int]string)
go func() {
	for {
		m[1] = "xx"
	}
}()

go func() {
	for {
		_ = m[1]
	}
}()
time.Sleep(time.Second * 3)

}

输出结果:

fatal error: concurrent map read and map write
// ...

阅读上面这段代码,我们并发读写 map 类型的变量 m,在运行时,返回致命错误 fatal error: concurrent map read and map write

Go 语言中的 map 在运行时是怎么检测到 map 的存在写操作?

源码:

const (
	// flags
	iterator     = 1 // there may be an iterator using buckets
	oldIterator  = 2 // there may be an iterator using oldbuckets
	hashWriting  = 4 // a goroutine is writing to the map
	sameSizeGrow = 8 // the current map growth is to a new map of the same size
)
// A header for a Go map.
type hmap struct {
	count     int // # live cells == size of map.  Must be first (used by len() builtin)
	flags     uint8
	B         uint8  // log_2 of # of buckets (can hold up to loadFactor * 2^B items)
	noverflow uint16 // approximate number of overflow buckets; see incrnoverflow for details
	hash0     uint32 // hash seed
buckets    unsafe.Pointer // array of 2^B Buckets. may be nil if count==0.
oldbuckets unsafe.Pointer // previous bucket array of half the size, non-nil only when growing
nevacuate  uintptr        // progress counter for evacuation (buckets less than this have been evacuated)

extra *mapextra // optional fields

}

// Like mapaccess, but allocates a slot for the key if it is not present in the map. func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer { // …

done: if h.flags&hashWriting == 0 { fatal(“concurrent map writes”) } h.flags &^= hashWriting if t.IndirectElem() { elem = *((*unsafe.Pointer)(elem)) } return elem }

阅读上面这段源码,我们可以发现在 hmap 结构体中的字段 flags,该字段用于标记 map 是否为写入状态。

在访问 map 时,通过判断 hmap.flagshashWriting 的值,可知是否有其它 goroutine 访问 map,如果有,则返回致命错误 fatal("concurrent map writes")

03 总结

本文介绍 Go 语言为什么不支持并发读写 map,Go 官方的说法是在多数情况下 map 只存在并发读操作,如果原生支持并发读写,即降低了并发读操作的性能。

通过阅读源码,我们了解到在运行时检测是否存在对 map 的写操作,如果存在,则返回致命错误。

读者朋友们在使用 map 时,要特别注意是否存在对 map 的并发写操作,如果存在,要结合 sync 包的互斥锁一起使用。


Golang Go语言为什么不支持并发读写 map?

更多关于Golang Go语言为什么不支持并发读写 map?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

4 回复

1.9 就有 sync.Map 了,不提是因为……不知道?
不过至少排除 AI 创作了。AI 肯定会提一下的。

更多关于Golang Go语言为什么不支持并发读写 map?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


不懂
是无法在未获互斥锁的情况下写入吗?还是写了可能坏?

如果是后者,我觉得不算“不支持”

在Golang(Go语言)中,map类型本身并不是线程安全的,这意味着它们不支持并发读写操作。这一设计决策主要基于以下几个原因:

  1. 性能考虑:Go语言的设计哲学之一是追求高性能。map的并发读写需要引入复杂的锁机制来确保数据一致性,这会增加内存开销和降低访问速度。对于大多数应用场景来说,性能是至关重要的,因此Go语言选择了不提供内置的线程安全map。

  2. 简化设计:保持map的简单性有助于减少潜在的bug和复杂性。如果map内置了并发控制,开发者可能会误以为所有操作都是安全的,从而忽略必要的同步措施。

  3. 提供替代方案:Go语言提供了其他并发数据结构,如sync.Map,它支持高效的并发读写操作。sync.Map使用了更复杂的内部机制来平衡性能和安全性,适用于需要并发访问的场景。

  4. 鼓励显式同步:Go语言鼓励开发者显式地管理并发,通过channel、mutex等同步原语来控制对共享资源的访问。这种设计有助于开发者更清晰地理解并发程序的行为,并更容易进行调试和优化。

综上所述,Go语言不支持并发读写map是为了追求高性能、简化设计和提供灵活的并发控制选项。在需要并发访问map的场景中,开发者可以使用sync.Map或其他同步机制来确保数据的一致性和安全性。

回到顶部