本文深入剖析 go 程序中因重复复用同一结构体变量并发送其地址到 channel 所引发的数据竞争（data race），解释为何接收端读取到的切片长度不一致，并提供两种安全、符合 go 语义的解决方案。
本文深入剖析 go 程序中因重复复用同一结构体变量并发送其地址到 channel 所引发的数据竞争（data race），解释为何接收端读取到的切片长度不一致，并提供两种安全、符合 go 语义的解决方案。
在 Go 并发编程中，channel 是协程间通信的核心机制，但若使用不当，极易引入隐蔽且难以复现的竞态问题。您提供的代码看似逻辑清晰：主线程循环 5 次，每次构造一个含 1000 个元素的 []int 并通过 channel 发送给多个工作 goroutine；后者持续从 channel 接收并打印切片长度。理论上，“Put”与“Get”应严格一一对应，输出均为 1000。然而实际运行结果却随机出现 0、1、16 等异常值——这正是典型的数据竞争（Data Race）表现。
根本原因在于：您在整个循环中始终复用同一个 Data 变量 d 的地址（&d），并将该地址反复发送至 channel。由于 Go 中 channel 传递的是值（此处为指针值），而非深拷贝结构体内容，所有 goroutine 实际上共享指向同一内存地址的指针。当主线程在下一次迭代中执行 d.data = []int{} 和 append(...) 时，它正在并发修改已被前序 goroutine 接收、但尚未完成读取的 d.data 底层数组。而 len(char.data) 的执行时机完全取决于调度器——可能发生在清空前、追加中途、或追加完成后，导致读取到任意中间状态，从而输出不可预测的长度。
值得注意的是，此问题在 Go Playground 上“总是正常”，是因为 Playground 运行在受控的单核模拟环境，goroutine 调度高度可预测，掩盖了竞态；而本地多核环境则充分暴露了该缺陷。添加 time.Sleep 仅是通过人为延缓主线程，降低竞争概率，并非治本之策。
✅ 正确解法一：每次发送新实例（推荐）
将 Data 实例声明移入循环体内，确保每次发送的都是独立内存对象：
for i := 0; i < ws; i++ {
d := Data{} // 每次创建全新实例
ar := []int{1}
d.data = make([]int, 1000)
for j := 0; j < 1000; j++ {
d.data[j] = ar[0]
}
ch <- &d // 发送新实例地址，安全
fmt.Printf("Put: %d\n", len(d.data))
}✅ 正确解法二：传递值而非指针（更符合 Go 风格）
将 channel 类型改为 chan Data（值类型），利用 Go 的值传递语义自动复制结构体：
ch := make(chan Data, ws) // 注意：此处为 chan Data，非 chan *Data
// 发送端：
ch <- d // 自动复制整个 Data 结构体（含 data 切片头）
// 接收端：
char, ok := <-ch // char 是独立副本，修改不影响其他 goroutine
fmt.Printf("Get: %d\n", len(char.data))⚠️ 注意事项：
- 若
Data结构体过大（如含 megabytes 级切片），值传递会带来额外内存开销，此时应优先采用解法一（指针 + 每次新建）； - 始终使用
go run -race main.go启动程序检测数据竞争； - 避免在循环中复用需并发访问的变量地址，这是 Go 并发编程的黄金戒律之一。
总结：Go 的并发安全不依赖“运气”，而源于对内存所有权和数据生命周期的显式管理。通过创建独立实例或利用值传递语义，我们能彻底消除此类竞态，写出确定、可靠、易维护的并发代码。
