17370845950

指针并发安全需分场景：①共享指针须加锁或用atomic（仅限指针值本身）；②避免捕获局部变量地址致悬垂指针；③sync.Pool中指针对象须重置状态；④channel传指针后所有权和线程安全责任转移给接收方。

共享指针变量未加锁导致数据竞争

多个 goroutine 同时读写同一个 *int、*sync.Mutex 或自定义结构体指针的字段时，Go 的 race detector 会报出 Data Race。这不是“指针本身不安全”，而是指针指向的内存被并发修改且无同步机制。

• 常见错误：把 var p *int 声明在全局或传入多个 goroutine 后直接 *p = 42
• 正确做法：用 sync.Mutex 保护解引用和赋值操作，或改用 sync/atomic（仅限基础类型如 *int32、*uint64）
• 注意：atomic.StorePointer 和 atomic.LoadPointer 操作的是指针值本身（即地址），不是它指向的数据；要原子更新指向内容，仍需锁或 CAS 循环

goroutine 捕获局部指针变量引发悬垂指针风险

当 goroutine 异步使用函数内局部变量的地址（比如 &x），而该函数已返回，栈上内存可能已被复用，导致读到脏数据或 panic。

• 典型场景：循环中启动 goroutine 并传入 &v，但 v 是循环变量，所有 goroutine 实际共享同一地址
• 修复方式：在循环体内显式创建新变量，例如 val := v; go func() { fmt.Println(*val) }()
• 编译器不会报错，但 go run -race 可能捕获部分情况；更稳妥的是避免传递局部变量地址给异步逻辑

sync.Pool 中存放指针对象的生命周期陷阱

sync.Pool 会缓存对象供复用，但如果存入的是指针（如 *bytes.Buffer），需确保其指向的底层数据不残留跨 goroutine 的状态或敏感信息。

• 问题：从 Pool 获取的 *bytes.Buffer 可能含有之前使用者写入的旧数据，直接 b.Write() 可能拼接脏内容
• 必须在 Put 前重置状态，例如调用 b.Reset()；若结构体无 Reset 方法，应手动清空字段
• 禁止将含闭包、channel 或活跃 timer 的指针放入 Pool —— 它们可能在下次 Get 时已失效或引发 panic

channel 传递指针时的线程安全责任转移

通过 channel 发送指针（如 ch ）本身是安全的，但接收方获得指针后，是否可并发访问其指向的数据，完全由业务逻辑约定，Go 不做约束。

• 误用：发送 *User 到 channel，多个 goroutine 接收后同时修改 u.Name，无锁即竞争
• 推荐模式：channel 传递只读语义的指针，并在文档或命名中明确（如 type UserView *User）；或传递副本（ch ）避免歧义
• 性能权衡：小结构体拷贝开销低，比维护指针同步逻辑更可靠；大对象才值得传指针，但务必配套同步方案

并发中指针最棘手的不是语法或运行时限制，而是“谁拥有修改权”这个隐含契约容易被忽略。一旦多个 goroutine 认为自己可以自由写入同一块内存，bug 就藏在偶发的调度顺序里。