Golang代码执行结果竟如此惊人

这是一个典型的并发数据竞争问题，涉及到Go语言的内存模型和编译器优化。让我详细分析一下这个现象：

问题分析

当注释掉 fmt.Printf("") 时，编译器可能会进行优化，导致goroutine看到的是切片 a 的旧值。而加上 fmt.Printf("") 后，这个函数调用阻止了某些优化，使得goroutine能够看到切片 a 的新值。

根本原因

这里存在数据竞争（data race），因为主goroutine和启动的goroutine在没有同步机制的情况下并发访问同一个切片。

package main

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

func in(d *[]int, wg *sync.WaitGroup) {
	defer wg.Done()
	fmt.Println(*d)
	time.Sleep(2 * time.Second)
	fmt.Println(*d)
}

func main() {
	var wg sync.WaitGroup
	a := []int{1,2,3}
	
	wg.Add(1)
	go in(&a, &wg)
	
	// 这里存在数据竞争
	a = []int{4,5,6}
	
	wg.Wait()
}

正确解决方案

方案1：使用互斥锁

package main

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

type SafeSlice struct {
	mu sync.RWMutex
	data []int
}

func in(s *SafeSlice, wg *sync.WaitGroup) {
	defer wg.Done()
	
	s.mu.RLock()
	fmt.Println(s.data)
	s.mu.RUnlock()
	
	time.Sleep(2 * time.Second)
	
	s.mu.RLock()
	fmt.Println(s.data)
	s.mu.RUnlock()
}

func main() {
	var wg sync.WaitGroup
	s := &SafeSlice{data: []int{1,2,3}}
	
	wg.Add(1)
	go in(s, &wg)
	
	s.mu.Lock()
	s.data = []int{4,5,6}
	s.mu.Unlock()
	
	wg.Wait()
}

方案2：使用通道进行通信

package main

import (
	"time"
	"fmt"
)

func in(ch <-chan []int, done chan<- bool) {
	data := <-ch
	fmt.Println(data)
	
	time.Sleep(2 * time.Second)
	
	data = <-ch
	fmt.Println(data)
	done <- true
}

func main() {
	ch := make(chan []int, 2)
	done := make(chan bool)
	
	go in(ch, done)
	
	ch <- []int{1,2,3}
	ch <- []int{4,5,6}
	
	<-done
}

方案3：使用原子操作（适用于简单类型）

package main

import (
	"time"
	"fmt"
	"sync/atomic"
)

type AtomicSlice struct {
	ptr atomic.Value
}

func (a *AtomicSlice) Store(slice []int) {
	a.ptr.Store(slice)
}

func (a *AtomicSlice) Load() []int {
	return a.ptr.Load().([]int)
}

func in(a *AtomicSlice, done chan bool) {
	fmt.Println(a.Load())
	time.Sleep(2 * time.Second)
	fmt.Println(a.Load())
	done <- true
}

func main() {
	a := &AtomicSlice{}
	done := make(chan bool)
	
	a.Store([]int{1,2,3})
	go in(a, done)
	
	a.Store([]int{4,5,6})
	<-done
}

关键要点

1. 避免数据竞争：在并发环境中访问共享数据必须使用同步机制
2. 不要依赖未定义行为：原代码的执行结果依赖于编译器的具体实现
3. 使用正确的同步原语：根据场景选择互斥锁、通道或原子操作

原代码中的无限循环 for {} 也应该避免，应该使用 sync.WaitGroup 或通道来正确等待goroutine完成。