golang 并发 append

go中，切片可以算是我们最常用的结构之一，但是如果不注意的话，在并发情况下，对同一个切片进行append，极有可能会造成线程不安全的情况。

非线程安全现象

如，以下例子:

func TestOther(t *testing.T) {
	testMap := []int{1,2,3,4}

	wg := sync.WaitGroup{}
	wg.Add(4)
	
	m := make([]int, 0)
	
	for _, v := range testMap {
		go func(v int) {
			defer wg.Done()

			m = append(m, v)
		}(v)
	}
	wg.Wait()

	t.Log(m)
}

以上代码，不同次运行时，输出以下这类不符合预期的结果：

这就是因为线程不安全导致的 (实际业务中，可以通过 go run -race main.go 进行检测程序的安全性)

原因分析

slice的数据结构:

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

使用append向Slice追加元素时，如果Slice空间不足，将会触发Slice扩容，扩容实际上重新一配一块更大的内存，将原Slice数据拷贝进新Slice，然后返回新Slice，扩容后再将数据追加进去。

在并发情况下，如果该slice始终空间不足，那么其是线程安全的，因为每次append实际都是新生成的内存，不存在抢占的情况。但是，当slice空间充足，也即是cap>len, 有剩余的空间时，比如说，下一个空闲内存是a, 那么并发情况下，就会出现多个线程抢占往a中写数据的情况。

slice扩容遵从以下原则:
如果原Slice容量小于1024，则新Slice容量将扩大为原来的2倍；
如果原Slice容量大于等于1024，则新Slice容量将扩大为原来的1.25倍；

所以，根据以上的原则，在程序运行后，是很容易就会出现有空闲空间的情况，也就会造成线程不安全的产生。

解决办法

针对内存占用，我们最直接简单的办法就是给内存加锁，如下:

func TestOther(t *testing.T) {
	testMap := []int{1,2,3,4}

	wg := sync.WaitGroup{}
	wg.Add(4)
	
	m := make([]int, 0)
	
	var lock sync.Mutex
	
	for _, v := range testMap {
		go func(v int) {
			defer wg.Done()

			lock.Lock()
			m = append(m, v)
			lock.Unlock()
			
		}(v)
	}
	wg.Wait()

	t.Log(m)
}

运行结果:

通过内存加锁，确保，同一时刻，只有一个线程对该块内存进行append操作，这就从根源上避免了抢占的问题。