如何在Golang中安全地并发访问和修改一个map-Golang-PHP中文网

在Go中并发访问map时，因内置map非线程安全，直接使用会导致数据竞争、panic或行为异常。为确保安全，推荐使用sync.RWMutex或sync.Mutex封装map。sync.RWMutex允许多个读、独占写，适合读多写少场景；sync.Mutex则简单粗暴，读写均互斥，适合读写均衡场景。此外，Go 1.9引入的sync.Map针对读多写少、键集稳定的场景优化，通过双map机制实现高效无锁读，但不支持直接len和range，且频繁写或键变动大时性能可能不如互斥锁方案。因此，多数通用场景仍推荐sync.RWMutex保护的标准map。

如何在golang中安全地并发访问和修改一个map

在Golang中安全地并发访问和修改一个

map

登录后复制

，最直接且推荐的方式是使用

sync

登录后复制

包提供的互斥锁，特别是

sync.RWMutex

登录后复制

（读写互斥锁）或

sync.Mutex

登录后复制

（互斥锁）。它们能有效避免数据竞争，确保操作的原子性和一致性。

解决方案

要安全地在Go中并发操作

map

登录后复制

，我们通常会将

map

登录后复制

封装在一个结构体中，并嵌入一个

sync.RWMutex

登录后复制

或

sync.Mutex

登录后复制

来保护它。

sync.RWMutex

登录后复制

提供了更细粒度的控制，允许多个读者同时访问，但在写入时会阻塞所有读写操作，这在读多写少的场景下性能更优。

sync.Mutex

登录后复制

则更为简单粗暴，无论读写，都只允许一个goroutine访问。

以下是一个使用

sync.RWMutex

登录后复制

保护

map

登录后复制

的示例：

package main

import (
    "fmt"
    "sync"
    "time"
)

// SafeMap 是一个并发安全的map封装
type SafeMap struct {
    mu    sync.RWMutex
    data  map[string]interface{}
}

// NewSafeMap 创建并返回一个新的SafeMap实例
func NewSafeMap() *SafeMap {
    return &SafeMap{
        data: make(map[string]interface{}),
    }
}

// Set 设置键值对
func (sm *SafeMap) Set(key string, value interface{}) {
    sm.mu.Lock() // 写入时加写锁
    defer sm.mu.Unlock()
    sm.data[key] = value
}

// Get 获取键对应的值
func (sm *SafeMap) Get(key string) (interface{}, bool) {
    sm.mu.RLock() // 读取时加读锁
    defer sm.mu.RUnlock()
    val, ok := sm.data[key]
    return val, ok
}

// Delete 删除键值对
func (sm *SafeMap) Delete(key string) {
    sm.mu.Lock() // 删除时加写锁
    defer sm.mu.Unlock()
    delete(sm.data, key)
}

// Len 返回map的长度
func (sm *SafeMap) Len() int {
    sm.mu.RLock() // 读取长度也需要读锁
    defer sm.mu.RUnlock()
    return len(sm.data)
}

func main() {
    safeMap := NewSafeMap()

    // 启动多个goroutine进行写入
    for i := 0; i < 10; i++ {
        go func(i int) {
            key := fmt.Sprintf("key%d", i)
            value := fmt.Sprintf("value%d", i*10)
            safeMap.Set(key, value)
            fmt.Printf("Set: %s = %s\n", key, value)
        }(i)
    }

    // 稍作等待，确保部分写入完成
    time.Sleep(100 * time.Millisecond)

    // 启动多个goroutine进行读取
    for i := 0; i < 15; i++ { // 故意多一些读取goroutine
        go func(i int) {
            key := fmt.Sprintf("key%d", i%10) // 读取已存在的或不存在的键
            val, ok := safeMap.Get(key)
            if ok {
                fmt.Printf("Get: %s = %v\n", key, val)
            } else {
                fmt.Printf("Get: %s not found\n", key)
            }
        }(i)
    }

    // 稍作等待，确保读写操作完成
    time.Sleep(500 * time.Millisecond)

    fmt.Printf("Final map length: %d\n", safeMap.Len())

    // 尝试删除一个键
    safeMap.Delete("key5")
    fmt.Println("Deleted key5")

    val, ok := safeMap.Get("key5")
    fmt.Printf("Get key5 after delete: %v, %t\n", val, ok)
}

登录后复制

为什么Go的内置map在并发环境下不安全？直接使用会发生什么？

这几乎是我在Go并发编程中遇到的第一个“坑”。Go的内置

map

登录后复制

并非设计为并发安全的。当多个goroutine同时对一个

map

登录后复制

进行读写操作时，会发生数据竞争（data race）。简单来说，就是不同的goroutine可能在同一时间修改或读取

map

登录后复制

的内部数据结构，导致其处于一个不一致或损坏的状态。

立即学习“go语言免费学习笔记（深入）”；

最常见且最糟糕的结果是程序会直接

panic

登录后复制

，并抛出

fatal error: concurrent map writes

登录后复制

或

concurrent map reads and writes

登录后复制

。这通常意味着运行时检测到了不安全的并发访问。但更隐蔽、更难以调试的问题是，即使不

panic

登录后复制

，你可能会读到错误的数据，或者

map

登录后复制

的内部结构被破坏，导致后续操作行为异常。例如，一个键可能突然“消失”，或者在迭代

map

登录后复制

时出现无限循环。这些都是因为

map

登录后复制

的底层实现，比如哈希桶的调整、链表的修改等，都不是原子操作。所以，一旦涉及并发，就必须采取额外的同步措施。

sync.Mutex

登录后复制

和

sync.RWMutex

登录后复制

之间如何选择？它们各自适用于哪些场景？

选择

sync.Mutex

登录后复制

还是

sync.RWMutex

登录后复制

，主要取决于你的

map

登录后复制

是读操作多还是写操作多。这就像在图书馆里，你是想让所有人都排队进出（

Mutex

登录后复制

），还是允许大家同时看书，但只有在有人要整理书架时才暂停所有人（

RWMutex

登录后复制

）。

```
sync.Mutex
```
登录后复制
(互斥锁)

图改改
在线修改图片文字

455

查看详情
- 特点： 简单粗暴，任何时候都只允许一个goroutine持有锁。无论是读还是写，都需要获取同一把锁。
- 适用场景：
  - 写操作频繁或读写比例接近1:1的场景。 在这种情况下，
```
RWMutex
```
    登录后复制
    的额外开销可能抵消不了它带来的并发读取优势。
  - 保护的数据结构操作简单，或者操作本身耗时较短。
  - 对性能要求不是极致，或者并发量不是特别高的场景。
```
Mutex
```
    登录后复制
    实现相对简单，开销也较小。
- 优点： 实现简单，不容易出错。
- 缺点： 读操作也会阻塞其他读操作，降低了并发度。
```
sync.RWMutex
```
登录后复制
(读写互斥锁)
- 特点： 允许多个读者同时持有读锁，但写者必须独占写锁。当一个写者持有写锁时，所有读者和写者都会被阻塞。当有读者持有读锁时，写者会被阻塞。
- 适用场景：
  - 读操作远多于写操作的场景。 这是
```
RWMutex
```
    登录后复制
    的“主场”。例如，一个配置缓存，大部分时间都在被读取，偶尔才更新。
  - 需要高并发读取性能的场景。
- 优点： 在读多写少的场景下，能显著提高并发读取性能。
- 缺点： 实现比
```
Mutex
```
  登录后复制
  复杂，有一定的额外开销。如果写操作非常频繁，
```
RWMutex
```
  登录后复制
  可能会导致写饥饿（writer starvation），即写操作长时间无法获取锁。

在我个人的实践中，如果不能确定读写比例，我通常会倾向于先使用

sync.RWMutex

登录后复制

。因为它的设计哲学更符合“读多写少”的常见应用模式，能带来更好的并发性。如果后续性能分析发现写操作是瓶颈，或者读写比例接近，再考虑切换到

sync.Mutex

登录后复制

。当然，过早优化是万恶之源，有时候

Mutex

登录后复制

的简洁性本身就是一种优势。

何时应该考虑使用

sync.Map

登录后复制

？它与传统互斥锁保护的map有何不同？

sync.Map

登录后复制

是Go 1.9版本引入的一个特殊的并发安全

map

登录后复制

实现。它并非一个通用的

map

登录后复制

替代品，而是针对特定使用模式进行优化的。我看到很多人一上来就想用

sync.Map

登录后复制

，觉得它是“更高级”的并发

map

登录后复制

，但实际上它有自己的适用边界。

```
sync.Map
```
登录后复制
的设计哲学与特点：
```
sync.Map
```
登录后复制
的设计目标是解决“键值对集合相对稳定，但每个键的值可能会频繁更新”，或者“读操作远多于写操作，且键值对集合会持续增长”的场景。它的内部实现非常巧妙，主要通过两个
```
map
```
登录后复制
（
```
read
```
登录后复制
和
```
dirty
```
登录后复制
）以及无锁或CAS操作来优化性能。
- ```
read
```
  登录后复制
  map：主要用于读操作，是无锁的，可以被多个goroutine同时读取。
- ```
dirty
```
  登录后复制
  map：包含所有最近写入的数据，以及
```
read
```
  登录后复制
  map中没有的数据。写操作会直接修改
```
dirty
```
  登录后复制
  map。
- 当
```
read
```
  登录后复制
  map中找不到数据时，会尝试从
```
dirty
```
  登录后复制
  map中查找，并可能将
```
dirty
```
  登录后复制
  map提升为新的
```
read
```
  登录后复制
  map，或者将
```
read
```
  登录后复制
  map中的数据复制到
```
dirty
```
  登录后复制
  map中，以便下次查找。
- 这种设计使得
```
Load
```
  登录后复制
  （读取）操作在大多数情况下是无锁的，非常高效。
```
Store
```
  登录后复制
  （写入）和
```
Delete
```
  登录后复制
  （删除）操作则可能涉及锁或CAS操作。
与传统互斥锁保护的
```
map
```
登录后复制
的主要区别：
1. 性能特性：
  - sync.Map
    登录后复制
    ：在“读多写少”且“键值对集合稳定”的场景下，
```
Load
```
    登录后复制
    操作的性能通常优于
```
RWMutex
```
    登录后复制
    保护的
```
map
```
    登录后复制
    ，因为
```
Load
```
    登录后复制
    在很多情况下是无锁的。然而，如果写操作非常频繁，或者键值对集合频繁变化，
```
sync.Map
```
    登录后复制
    的性能可能反而不如
```
RWMutex
```
    登录后复制
    ，因为其内部的
```
dirty
```
    登录后复制
    map同步和提升机制会带来额外开销。
  - Mutex
    登录后复制
    /
    RWMutex
    登录后复制
    保护的
    map
    登录后复制
    ：性能表现相对稳定，不会因为读写模式的极端变化而出现剧烈波动。
2. API差异：
  - sync.Map
    登录后复制
    ：提供了
```
Load
```
    登录后复制
    、
```
Store
```
    登录后复制
    、
```
Delete
```
    登录后复制
    、
```
LoadOrStore
```
    登录后复制
    、
```
Range
```
    登录后复制
    等方法。它没有
```
len()
```
    登录后复制
    方法，也不能直接迭代（需要使用
```
Range
```
    登录后复制
    方法传入一个回调函数）。
  - 传统
    map
    登录后复制
    ：可以直接使用
```
len()
```
    登录后复制
    获取长度，使用
```
for range
```
    登录后复制
    进行迭代。
3. 内存占用：
  - ```
  sync.Map
```
  登录后复制
  由于其内部维护了两个
```
  map
```
  登录后复制
  以及一些额外的元数据，在某些情况下可能会比普通
```
  map
```
  登录后复制
  占用更多的内存。
4. 适用场景：
  - sync.Map
    登录后复制
    ：适用于以下场景：
    - 键值对集合相对稳定，但值会频繁更新。 例如，缓存中存储的对象经常更新其状态。
    - 大量的读取操作，少量的写入操作。
    - 多个goroutine独立地读写不相交的键。
  - Mutex
    登录后复制
    /
    RWMutex
    登录后复制
    保护的
    map
    登录后复制
    ：适用于更通用的并发
```
map
```
    登录后复制
    需求，尤其是在写操作频繁、键值对集合变化大，或者需要直接访问
```
map
```
    登录后复制
    的
```
len()
```
    登录后复制
    和
```
for range
```
    登录后复制
    迭代的场景。