背景

最近开发的时候写了下面这段类似的代码。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

func TestAppend() (result []int) {
	var wg sync.WaitGroup
	for i := 0; i < 100; i++ {
		v := i
		wg.Add(1)
		go func() {
			// other logic
			result = append(result, v)
			wg.Done()
		}()
	}

	wg.Wait()
	//fmt.Printf("%v\n", len(result))
	return result
}

就像这样，然后顺利通过测试到达生产环境。然后就出问题了。

预期情况下，len(result) = 100, 但是大多数情况下，这个数据会<=100。因为append这个函数不是并发安全的。也就是不能在多个goroutine里面对同一个slice使用append进行追加。

那么问题出在哪呢？

我们都知道slice是对数组一个连续片段的引用，当slice长度增加的时候，可能底层的数组会被换掉。在换底层数组之前，切片同时被多个goroutine拿到，并执行append操作。那么很多goroutine的append结果会被覆盖，导致n个gouroutine append后，长度小于n。

你以为这是最坏的影响吗，并不是的。数据出bug了是小事，最坏的影响是直接服务直接panic。
append咋还导致服务panic呢？且往下看。

原因分析

要分析这个原因，我们需要了解slice的底层结构。

1
2
3
4
5

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

可以看到，array是一个指向具体数组的指针，len是当前已经使用的长度，使用append的时候会再下一个位置填充数据并且把len加1。不加锁的情况下，由于操作并非原子的，可能两个goroutine同时往同一个位置写数据，就会导致数据覆盖。最终的长度小于实际期待的长度。

问题解决

有两种方案解决这个问题。

方案1

可以给append操作加锁，这样就会保证操作操作的原子性。不会被另一个goroutine打断。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

func TestAppendWithLock() (result []int) {
	var wg sync.WaitGroup
	var lock sync.Mutex
	for i := 0; i < 100; i++ {
		v := i
		wg.Add(1)
		go func() {
			defer wg.Done()
			lock.Lock()
			result = append(result, v)
			lock.Unlock()

		}()
	}

	wg.Wait()
	//fmt.Printf("%v\n", len(result))
	return result
}

方案2

如果slice的长度固定的情况下。可以直接使用make初始化固定长度，并使用下标赋值。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

func TestSliceAppend() (result []int) {
	var wg sync.WaitGroup
	result = make([]int, 100)
	for i := 0; i < 100; i++ {
		wg.Add(1)
		go func(index int) {
			defer wg.Done()
			result[index] = index
		}(i)
	}

	wg.Wait()
	//fmt.Printf("%v\n", len(result))
	return result
}

panic原因

这个panic是概率性的，有非常小的概率会发生，但是在高并发场景下，是必定会发生的。

我们写个循环不停的执行并发append的函数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

func TestAppend() (result []int) {
	var wg sync.WaitGroup
	for i := 0; i < 100; i++ {
		v := i
		wg.Add(1)
		go func() {
			// other logic
			result = append(result, v)
			wg.Done()
		}()
	}

	wg.Wait()
	//fmt.Printf("%v\n", len(result))
	return result
}

func main() {
	for a := 0; a < 100000; a++ {
		res := TestAppend()
		println("len(res):", len(res))
	}
}

使用循环不停的执行并发append操作。过一段时间你就会发现：

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x108933f]

goroutine 9278997 [running]:
main.TestAppend.func1(0xc00020e050, 0xc0005da040, 0x3)
        /Users/left_pocket/concurrency_append/main.go:20 +0x6f
created by main.TestAppend
        /Users/left_pocket/concurrency_append/main.go:18 +0xa6

Process finished with exit code 2

的报错。 正是

1

result = append(result, v)

这一行。

这个报错曾经导致生产环境的service偶尔crash，这个概率非常低。 我们使用*-race*的参数执行函数

go run -race main.go

可以看到DATA RACE的报错。

==================
WARNING: DATA RACE
Read at 0x00c000100000 by goroutine 8:
  runtime.growslice()
      /Users/left_pocket/go1.14/src/runtime/slice.go:76 +0x0
  main.TestAppend.func1()
      /Users/left_pocket/src/github.com/left-pocket/go-practice/concurrency_append/main.go:20 +0x179

找到go语言库的代码。

1
2

func growslice(et *_type, old slice, cap int) slice {  //line 76
}

发现了RACE CONDITION。 使用goland的debug模式继续分析。

发现是在growslice函数里面调用memmove的时候发生了panic。可以确认是在slice扩容的过程中panic。
也就是恰好在append扩容的时候，两个goroutine同时进行memmove。

可以在TestAppend里面加一行代码，预先分配容量，来间接验证是扩容会产生panic。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

func TestAppend() (result []int) {
	var wg sync.WaitGroup
	result = make([]int, 0, 100) //set capacity first, will not add capacity anymore
	for i := 0; i < 100; i++ {
		v := i
		wg.Add(1)
		go func() {
			defer wg.Done()
			result = append(result, v)
		}()
	}

	wg.Wait()
	return result
}

如果调用前初始化了capacity，就不会导致panic。

总结

Golang append并不是并发安全的，我相信使用过Golang的同学大部分都是知道的，但是他有概率会导致服务crash，这才是更大的风险。

<全文完>