17370845950

指针参数本身不破坏线程安全，真正引发问题的是多个goroutine并发读写同一堆内存且无同步；只读或每次新建指针则安全，共享可变状态必须加锁或原子操作。

指针参数本身不破坏线程安全，但共享可变

状态会

Go 中函数传指针只是传地址副本，和传 int 或 string 一样是值传递。真正引发线程安全问题的，是多个 goroutine 同时读写同一块堆内存（比如指向同一个结构体的多个指针），且未加同步控制。

常见错误现象：fatal error: concurrent map writes、数据竞态（race）被 go run -race 检出、结构体字段值“随机”错乱。

• 如果指针指向的是只读数据（如 const 初始化的全局结构体），或每次调用都新建（&MyStruct{}），通常无风险
• 若多个 goroutine 共享一个指针变量（如闭包捕获、全局变量、channel 传递后复用），且对所指对象做写操作，就必须加锁或改用原子操作
• 切片、map、channel 本身是引用类型，即使不传指针，它们的底层数据也可能被并发修改——这点常被误认为“没传指针就安全”

goroutine 间通过指针共享结构体时，必须显式同步

比如一个计数器结构体被多个 goroutine 通过指针访问：

type Counter struct {
    mu sync.Mutex
    n  int
}
func (c *Counter) Inc() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.n++
}

这里 *Counter 是参数类型，但关键不是“用了指针”，而是 c.mu 提供了临界区保护。漏掉 Lock()/Unlock()，哪怕只改一个字段，也会触发竞态。

• 不要依赖“小字段写入是原子的”：x86 上 int64 对齐写入虽常原子，但 Go 内存模型不保证，且跨平台不可靠
• 避免在锁内做耗时操作（如 HTTP 调用、大循环），否则阻塞其他 goroutine
• 优先用 sync/atomic 操作基础类型（int32、uint64、指针），比互斥锁更轻量

channel 传递指针需格外小心生命周期

通过 channel 发送指针（如 ch ）很常见，但容易忽略：接收方可能在发送方已释放该内存后继续使用它。

典型场景：循环中复用局部变量地址：

for _, v := range data {
    go func() {
        ch <- &v // ❌ 所有 goroutine 都指向同一个 v 的地址，值不断被覆盖
    }()
}

正确做法是传值或确保地址唯一：

• 改用值传递：ch （前提是 v 可拷贝且代价可控）
• 在循环内取地址：val := v; ch
• 用 sync.Pool 管理临时对象指针，避免 GC 压力与悬垂指针

这类 bug 不报 panic，但会导致读到脏数据或崩溃，调试难度高。

interface{} 包装指针时，竞态检测可能失效

当把指针转为 interface{}（如塞进 map[interface{}]interface{} 或 channel chan interface{}），go build -race 可能无法跟踪到底层指针指向的内存是否被并发访问。

• 竞态检测器依赖静态分析指针来源，而 interface{} 擦除了类型信息，导致漏报
• 避免用 interface{} 作为“通用容器”传递可变状态指针；优先定义具体类型或使用泛型
• 若必须用，确保所有对该指针的访问路径都在同一同步机制下（如统一由某个 sync.RWMutex 保护）

最易被忽略的是：指针安全与否，不取决于它“是不是参数”，而取决于“谁持有它、何时读写、有没有协调”。写并发代码时，盯着内存归属，而不是语法形式。