Go 语言中哪些类型不支持并发安全？

在 Go 语言的高性能并发模型中，Goroutine 的轻量化让多线程编程变得异常简单。出于对单线程执行效率与“无锁即最高性能”的追求，Go 官方团队在设计标准库与内置数据类型时，遵循了极简锁原则（Zero overhead for unused locks）。这意味着除了少数显式设计用于并发通信的结构外，Go 语言中绝大多数内置数据类型与标准库结构体在并发修改或读写混用时，都是非并发安全的。了解这些类型的边界与底层失效机理，是写出高可用 Go 服务的必备基本功。

map：并发读写引发致命崩溃

在 Go 各种数据类型中，map 对并发写的容忍度最为严格。一旦检测到并发读写或并发写写，程序不会抛出可恢复的 panic，而是调用 fatal error 直接终止整个进程。

map 内部在最新 Go 版本（Swiss Table 架构）的 internal/runtime/maps 包中，通过 writing 标志维护当前写入状态。在发起读写操作前，系统会实时检测该标志：

// 伪代码：Go 最新源码 internal/runtime/maps/map.go 内部并发校验逻辑
if m.writing != 0 {
    fatal("concurrent map read and map write")
}
m.writing = 1 // 标记写入中

这种硬核的崩溃机制旨在防止由于哈希桶结构在并发迁移过程中损坏导致更严重的内存泄漏。并发场景下操作 map，必须使用 sync.RWMutex 显式加锁，或在读多写少、键空间重叠率低的场景下使用 sync.Map。

slice：并发追加导致脏数据与覆盖

slice（切片）在 Go 语言中本质上是一个占用 24 字节（64 位架构）的 Header 结构体，内部包含指针 array、长度 len 以及容量 cap。

对 slice 执行并发 append 时，由于读取 len、计算新位置、写入数据与更新 len 这四个步骤缺乏原子保护，极易发生竞态条件。

// 演示并发 append 冲突
var slice []int
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
    wg.Add(1)
    go func(v int) {
        defer wg.Done()
        slice = append(slice, v) // 非原子操作，导致元素被覆盖
    }(i)
}
wg.Wait()

上述代码执行完成后，len(slice) 的实际结果通常远小于 1000。这是因为多个 Goroutine 同时拿到了相同的 len 旧值，并将元素覆盖写入同一个数组索引位置。若部分 Goroutine 在追加时触发了动态扩容并分配了新底层数组，而另一些 Goroutine 仍向旧数组追加，还会导致切片变量指向的底层数组发生割裂，部分写入的数据彻底从主切片视图中丢失。并发切片写入应提前分配固定容量，并利用协程索引分割写区域，或者使用互斥锁防护。

string 与 interface：内存赋值的字撕裂风险

很多开发者误以为 string 或 interface{} 只是简单的标量，赋值操作天生原子。其实在 64 位 CPU 下，单次 CPU 寄存器原子写入上限通常为 8 字节（64 位），而 string 和 interface{} 的底层尺寸均为 16 字节。

string 由 8 字节 Data 指针和 8 字节 Len 组成；interface{} 则由 8 字节 type 类型信息指针和 8 字节 data 数据指针组成。

// 并发修改 string 变量引发字撕裂
var target string
go func() {
    for { target = "a very long string payload..." }
}()
go func() {
    for { target = "short" }
}()

当两个 Goroutine 并发修改同一个 string 变量时，可能发生 Word Tearing（字撕裂）。即 target 的 Data 指针已指向长字符串内存，但 Len 却仍保留短字符串的长度（或反之）。若指针指向了新地址，但 Len 超出了新地址的实际边界，后续切片或读取操作便会触发内存越界崩溃（Panic: runtime error）。

struct 与指针：多字段修改的状态乱序

与切片和接口类似，普通的 struct 包含多个成员变量。多个 Goroutine 并发修改结构体中的不同字段，虽然不会直接导致内存越界，但无法保证字段间更新的时序一致性。

对于普通的结构体指针 *T，在 64 位机器下指针本身的读写虽然是单机器字（8 字节）操作，但由于缺乏同步屏障（Happens-Before 关系），CPU 和编译器的指令重排序与缓存内存可见性会导致竞态风险。写端可能刚分配了结构体并写完字段，读端就已经获取到了新指针，但在读取结构体内部字段时却读到了未完成初始化的旧值或零值。若要实现指针或复合结构体的无锁并发更新，需借助 sync/atomic 包中的 atomic.Pointer[T] 或 atomic.Value 完成带有内存同步屏障的原子替换。

bytes.Buffer 与 strings.Builder：内部状态溢出

除了语言内置类型外，Go 标准库中用于高性能字节拼装的 bytes.Buffer 和 strings.Builder 同样是不支持并发安全的。

这两个结构体内部维护了 []byte 缓冲区以及记录读取位置的 off 偏移量。

// bytes.Buffer 并发写入示例
var buf bytes.Buffer
for i := 0; i < 100; i++ {
    go func(id int) {
        fmt.Fprintf(&buf, "data-%d\n", id) // 并发修改内部 off 与 slice
    }(i)
}

并发调用 Write 或 Read 方法会导致 off 字段读写竞态，破坏内部切片的边界逻辑，进而抛出 index out of range 异常或拼装出损坏的非法数据。在并发日志拼接或通道拆分场景中，每个 Goroutine 应当持有独立的 Buffer 实例，最后再统一刷入 I/O 链路。

并发安全识别与防范范式

在 Go 生态体系中，仅有少数特定类型原生支持并发安全：

支持并发安全的类型包括 channel（内置 hchan 锁）、sync.Map、sync.Pool 以及 sync/atomic 包提供的原子类型。值得注意的是，虽然 channel 的收发是安全的，但并发重复关闭同一个 channel 依旧会触发 panic。

对于所有只读数据，任何类型在没有写操作的前提下都是并发安全的。一旦涉及状态变更，必须引入同步机制。

为避免并发安全陷阱遗留到生产环境，应当将 Go 官方提供的 Race Detector（竞态检测器）集成到本地测试与 CI/CD 流程中：

# 在单元测试与构建时开启竞态检测
go test -race ./...
go build -race -o main .

-race 参数会在编译期插入插桩代码，运行时检测内存访问指令。一旦发现两个 Goroutine 在未加同步锁的情况下访问同一块内存且至少有一个为写操作，就会实时打印包含 Goroutine 堆栈的警告日志。

总结来看，理解 Go 语言类型系统的并发安全边界，遵循“只读共享、写时同步”的原则，配合 -race 工具自动化检测，能够有效在开发早期拦截绝大多数诡异的并发 Bug。