不当的使用goroutine，可能会使CPU忙于移动数据，导致减慢代码运行速度的效果。
这里我们假设有一个很大的循环；为了加快计算速度，将循环分割成多份，然后分别让不同的goroutine执行。
1、串行版本
我们的使用一个简单的串行循环（除了总结循环索引之外什么都不做）作为例子来说明问题。
const (
limit = 10000000000
)
func SerialSum() int {
sum := 0
for i := 0; i < limit; i++ {
sum += i
}
return sum
}
上述代码只是将 1～limit 之间所有数字求和。
2、并发版本
下面我们使用goroutine优化
func ConcurrentSum() int {
n := runtime.GOMAXPROCS(0)
sums := make([]int, n)
wg := sync.WaitGroup{}
for i := 0; i < n; i++ {
wg.Add(1)
go func(i int) {
start := (limit / n) * i
end := start + (limit / n)
for j := start; j < end; j += 1 {
sums[i] += j
}
wg.Done()
}(i)
}
wg.Wait()
sum := 0
for _, s := range sums {
sum += s
}
return sum
}
3、遗憾的结果
遗憾的是 结果是负向的
func BenchmarkSerialSum(b *testing.B) {
for i := 0; i < b.N; i++ {
SerialSum()
}
}
func BenchmarkConcurrentSum(b *testing.B) {
for i := 0; i < b.N; i++ {
ConcurrentSum()
}
}
我们使用上述代码进行测试：
$ go test -bench .
goos: darwin
goarch: amd64
pkg: github.com/appliedgo/concurrencyslower
BenchmarkSerialSum-4 1 6090666568 ns/op
BenchmarkConcurrentSum-4 1 15741988135 ns/op
PASS
ok github.com/appliedgo/concurrencyslower 21.840s
从结果中我们可以看到，使用goroutine的并发版本是串行版本的约2.5 倍
4、硬件加速的反击
为了解释这种违反直觉的结果，我们必须看一下所有软件--CPU芯片下面的东西。
问题的原因在于缓存内存有助于加速每个CPU核心。
为了清晰和简洁，以下是一个粗略的过度简化。 每个现代CPU都有一个非平凡的缓存层次结构，位于主内存和裸CPU内核之间，但出于我们的目的，我们只会查看属于各个内核的缓存。
5、CPU缓存的目的
一般来说，缓存是一个非常小但超快的内存块。 它位于CPU芯片上，因此每次读取或写入值时，CPU都不必到达主RAM。 相反，该值存储在缓存中，后续读取和写入受益于更快的RAM单元和更短的访问路径。
CPU的每个核心都有自己的本地缓存，不与任何其他核心共享。 对于n个CPU内核，这意味着最多可以有n + 1个相同数据的副本; 一个在主内存中，一个在每个CPU内核的缓存中。
现在，当CPU内核更改其本地缓存中的值时，必须在某个时刻将其同步回主内存。 同样，如果缓存的值在主内存中被更改（由另一个CPU内核），则缓存的值无效，需要从主内存刷新。
6、缓存行
为了以有效的方式同步高速缓存和主存储器，数据以通常64字节的块同步。 这些块称为缓存行。
因此，当缓存值更改时，整个缓存行将同步回主内存。 同样，包含此高速缓存行的所有其他CPU核心的高速缓存现在也必须同步此高速缓存行以避免对过时数据进行操作。
7、邻居
这对我们的代码有何影响？ 请记住，并发循环使用全局切片来存储中间结果。 切片的元素存储在连续的空间中。 概率很高，两个相邻的切片元素将共享相同的高速缓存行。
有n个高速缓存的n个CPU内核重复读取和写入全部位于同一高速缓存行中的切片元素。 因此，只要一个CPU内核使用新的总和更新“其”切片元素，所有其他CPU的高速缓存行就会失效。 必须将更改的高速缓存行写回主内存，并且所有其他高速缓存必须使用新数据更新其各自的高速缓存行。 即使每个核心访问切片的不同部分！
这消耗了宝贵的时间 - 超过了串行循环更新其单个和变量所需的时间。
这就是我们的并发循环比串行循环需要更多时间的原因。 对切片的所有并发更新都会导致繁忙的缓存行同步跳跃。
8、传送数据
既然我们知道了速度放缓的原因，那么解决方案就是显而易见的。 我们必须将切片转换为n个单独的变量，这些变量有望彼此远离存储，以便它们不共享相同的高速缓存行。
所以让我们改变我们的并发循环，以便每个goroutine将其中间和存储在goroutine-local变量中。 为了将结果传递回主goroutine，我们还必须添加一个通道。 这反过来允许我们删除等待组，因为通道不仅是通信的手段，而且是优雅的同步机制。
9、使用局部变量并发循环
func ChannelSum() int {
n := runtime.GOMAXPROCS(0)
res := make(chan int)
for i := 0; i < n; i++ {
go func(i int, r chan<- int) {
sum := 0
start := (limit / n) * i
end := start + (limit / n)
for j := start; j < end; j += 1 {
sum += j
}
r <- sum
}(i, res)
}
sum := 0
for i := 0; i < n; i++ {
sum += <-res
}
return sum
}
在我们的测试文件中添加第三个基准测试功能BenchmarkChannelSum之后，我们现在可以在循环的所有三个变体上运行基准测试。
$ go test -bench .
goos: darwin
goarch: amd64
pkg: github.com/appliedgo/concurrencyslower
BenchmarkSerialSum-4 1 6022493632 ns/op
BenchmarkConcurrentSum-4 1 15828807312 ns/op
BenchmarkChannelSum-4 1 1948465461 ns/op
PASS
ok github.com/appliedgo/concurrencyslower 23.807s`
将中间和扩展到各个局部变量，而不是将它们放在一个片中，这无疑帮助我们逃避了缓存同步问题。
但是，我们如何确保各个变量永远不会共享同一个缓存行？ 好吧，启动一个新的goroutine会在堆栈上分配2KB到8KB的数据，这比64字节的典型缓存行大小要多。 并且由于中间和变量不是从创建它的goroutine之外的任何地方引用的，因此它不会转移到堆（它可能最终接近其他中间和变量之一）。 所以我们可以非?？隙挥辛礁鲋屑浜捅淞炕嵩谕桓龌捍嫘兄薪崾?/p>
