《Concurrency in Go》

本章节从goroutine入手，讲解go语言的各种并发原语。在讲解完goroutine之后，对于传统的内存同步访问的并发原语：sync包中的Mutex，RWMutex，Cond，Once，WaitGroup，Pool等进行了分析。在此之后着重讲了go语言的另一大特色：channel。在最后，讲解了如何结合channel的语法：select语句。

插一句题外话：这本书的中文版本的翻译就是一坨屎。

Chapter 3：Go’s Concurrency Building Blocks Go 语言并发组件

1. goroutine

goroutine是Golang中最基本的组织单位之一，每个go语言的程序都至少有一个goroutine：main goroutine，它在进程开始时自动创建并且启动。

1.1 什么是goroutine？

简单的说：goroutine是一个并发的函数，可以和别的代码块同时运行（不一定是并行的）。

至于如何使用go关键字来简单的创建一个goroutine，就不多讲了，看到这个博客的人估计没那么傻。

golang中的goroutine是这个世界上独一无二的东西。它不是OS线程，也不是绿色线程（由语言运行时管理的线程）。有些中文的翻译为轻量线程，但是事实上goroutine is a coroutine，也就是说goroutine是一个协程。协程是一种非抢占式的特殊线程（进程和线程是抢占式的）。协程不能被中断，但是协程尤多个允许暂停和重新进入的点。

1.2 goroutine的独到之处（和普通协程的区别）

goroutine的独到之处在于它们与golang的运行环境的深度集成。（原文是：What makes goroutines unique to Go are their deep integration with Go’s runtime. 这里的所谓golang的运行环境其实是特指的golang的runtime | 在中文翻译中为：它们与Go语言运行时的深度集成，这根本就不通顺嘛！）

goroutine定义了自己的暂停的方法和再切入的点。Go语言的runtime会观察goroutine的运行时的行为，并且在阻塞的时候自动挂起它们，然后在不被阻塞的时候再恢复。 在golang的runtime和goroutine的逻辑之间有一种优雅的伙伴一样的关系。

1.3 goroutine怎么实现并发

协程（coroutine）和goroutine都是隐式并发结构，这说明并发并不是协程的属性：必须同时托管多个协程，并且给每个协程一个执行的机会。

Golang的主机托管机制是一个M：N调度器，主要机制就是将M个由程序管理的线程映射到N个OS线程。而M：N调度器可以单独写一个博客了，这里就不再细说。

Golang遵循一个称为fork-join的并发模型。

fork是指在程序运行中的任意一点，它可以将执行的子分支和父节点同时运行。
join这个词是指的是在将来的某个时候，这个并发的执行分支将会合并在一起。

在fork-join模型中，掌握join的点是至关重要的，因为join点是保证程序的正确性和消除竞争条件的关键。而控制join点的关键技术是WaitGroup。

1.4 goroutine中闭包运行的情况

我们在快速创建goroutine的时候往往会选择使用匿名函数来创建，这就牵扯到了闭包中变量的引用问题：闭包可以从创建它们的作用域中获取变量，那么当这个闭包运行的时候，调用这些变量的方式是副本还是引用呢？

举个例子：

var wg sync.WaitGroup
salutation := "hello"
wg.Add(1)
go func() {defer wg.Done()salution = "welcome"
}()
wg.Wait()
fmt.Println("Out:", salutation)

我的得到的输出是：

Out: welcome

事实证明，goroutine在它们所创建的相同地址空间内执行。
从另一个角度再进行一个实验：

var wg sync.WaitGroup
for _, salutation := range []string{"hello", "greetings", "good day"} {wg.Add(1)go func() {defer wg.Done()fmt.Println(salutation)}()
}
wg.Wait()

这个程序我们期望得到的结果是：

hello
greetings
good day

以上的所有可能的排列组合，因为我们都知道并发所带来的竞争条件产生的影响，但是输出却让我们大吃一惊：

good day
good day
good day

当大家看到输出的时候应该已经明白了究竟是怎么回事：在输出之前，salutation就已经完成了迭代。

但是值得注意的一点是，既然迭代已经结束，为什么还能使用salutation的引用呢？这个就和golang的GC有关，golang的GC会小心的把salutation的引用从内存转移到堆，以便能够继续使用。

所以正确的程序应该这样编写：

var wg sync.WaitGroup
for _, salutation := range []string{"hello", "greetings", "good day"} {wg.Add(1)go func(salutation string) {defer wg.Done()fmt.Println(salutation)}(saluation)
}
wg.Wait()

也就是传入数据的副本。

由于所有的goroutine都在相同的地址空间中运行，而且只有简单的宿主函数，所有使用goroutine编写并发的任务是非常的自然的，golang的编译器很好的处理了内存中的变量，这样goroutine就不会意外的访问被释放的内存，这使得开发人员可以专注于它们的问题是如何被解决的，而不需要去消耗更多精力来管理内存。

但是golang带来的这些好处也付出了一些代价，由于多个goroutine运行在同一个地址空间，所以我们仍然需要担心同步问题。解决问题的方法：sync包和channel我们会在后面的小节进行讨论。

1.5 goroutine有多么的轻量级

以下是摘自Go Programming Language FAQ中的一段话。

这段话很夸张的说出：在同一个地址空间中创建成千上万的goroutine是可行的。

这是吹牛逼吧！怎么可能！

但是goroutine就是这么轻量，一个goroutine只有几千个字节，这完全是ok的。

但是当进程多了起来，一个问题将明显的影响着程序的性能：上下文之间的切换。当进程之间来回不断的切换的时候，保存现场和恢复现场的工作显得格外耗时，那么goroutine这么多，在它们之间的切换应该也相当耗时吧？

但是并不！goroutine之间的切换速度是OS线程切换速度的8%！

太轻了，实在是太轻了。goroutine的使用代价如此的小让我们能够放手的去用goroutine解决并发问题。

2. Package `sync`

sync包包含了对于低级别内存访问同步最有用的并发原语。很简单，很基础。

2.1 WaitGroup

当你不关心并发操作的结果，或者你又其他的方法能够收集它们的结果的时候。WaitGroup是等待一组并发操作完成的好办法。

你可以将WaitGroup视为一个并发安全的计数器。

func (wg *WaitGroup) Add(delta int)
// Add 方法增加计数器的增量。
func (wg *WaitGroup) Done()
// 调用Done方法来对计数器进行递减。
func (wg *WaitGroup) Wait()
// Wait方法会阻塞，直至计数器为0.

使用WaitGroup的时候需要注意的是：Add方法的调用应该是在跟踪的goroutine之外调用的。如以下程序为例：

// 正确的示例
var wg sync.WaitGroup
for i:=0; i<10; i++ {wg.Add(1)go func() {// wg.Add(1) 如果在这里调用wg.Add()会让程序直接结束。因为竞争条件。defer wg.Done()fmt.Println("Hello")}
}
wg.Wait()

2.2 Mutex & RWMutex

锁，这一节讲的就是锁。不管是在数据库中还是在一些传统的并发处理中，锁往往都是我们最常见的方式或者方法。而在sync包中有Mutex和RWMutex两种锁，分别是互斥锁和读写锁。

2.2.0 Locker

sync包中有一个锁接口，具体定义如下。

type Locker interface {Lock()Unlock()
}

2.2.1 Mutex 互斥锁

互斥是保护程序中临界区的一种方式，临界区是程序中需要独占访问共享资源的区域。Mutex提供了一种安全的方式来表示对这些共享资源的独占访问。

为了使用一个资源，channel通过通信的方式来共享内存，而Mutex通过开发人员的约定来同步访问共享内存。

在使用的时候，往往会将共享资源和互斥锁绑定在一起：

type NewResource struct {Resource []interface{}Lock     *sync.Mutex
}

使用时通过使用sync.Mutex.Lock()方法和sync.Mutex.Unlock()方法来声明对于资源的独占开始和结束。

最好使用 defer关键字来结束独占，否则可能因为panic引发死锁

在此之前我们介绍了原子操作的概念，也就是一个操作的原子性。事实上我们在对于一个资源的独占期间我们绝对不想要被打断，也就是说在对于资源的操作的上下文下，我们对于资源独占期间的操作整体是具有原子性的，而又结合我们之前接触过的所谓饥饿的概念，我们知道，我们的临界区应该尽可能的小，也就是我们独占的时间应该尽可能的小。因此一个良好的Mutex的使用应该像下面这样：

go func(resource) {init() // 和资源无关的操作resource.Lock.Lock()defer resource.Lock.Unlock()resource.Operation() // 对于资源的操作
}(resource_1)

2.2.2 RWMutex 读写互斥锁

读写锁在概念上和和互斥锁是一样的，但是读写锁让你对于内存有了更多的控制，也就是你可以单独请求一个锁用于读处理，这个情况下你将被授予访问权限。

2.3 cond 条件变量

Cond实现了一个条件变量，是一些正在等待或者声明一个事件的goroutine的集合点。

每一个Cond都有一个相关联的锁，必须在条件改变和调用wait()时进行状态的改变。

在上述的定义中，有一个重要的概念：事件。这里的事件（Event）是指两个或者两个已上的goroutine之间的任意信号，除去这个事件已经发生之外，没有任何的信息能够被我们利用。

先看一下在不使用cond的时候我们应该怎样检查这个事件是否完成。

for conditionTrue() == false {}
then()

使用一个死循环来检查！这太聪明了！但是这样会消耗你所有的CPU时钟周期！

因此我们可以定时来检查一下？

for !conditionTrue() {time.Sleep(1*time.Millisecond)
}
then()

这显然比死循环好多了，但是也是相当低效的行为，而且对于休眠的时间长度也要有所掌控：太长，会人为的降低性能；太短，会不必要地消耗大量的CPU时间。而cond就是为了解决这种问题而生的。

让我们使用cond来改写之前的例子：

cond := sync.NewCond(&sync.Mutex{}) // new一个新的cond
cond.L.Lock() // 锁定条件，因为在执行cond.Wait()的时候会自动调用Unlock()
for !conditionTrue() {cond.Wait() // 开始等待，在另一个goroutine中发送信号来终止等待
}
c.L.Unlock() // 解锁这个条件，而Wait()方法在退出的时候会自动调用Lock()

Wait()方法不只是阻塞了goroutine，还挂起了当前的goroutine，允许其他goroutine在OS线程上运行。

这里介绍了为什么使用循环来判定，而并非只使用if语句：因为当Wait()第一次返回的时候我们不能认为条件成立了，因此需要循环等待。但是这显然要比之前的两种方法高效多了。

其他的能够很好的体现的cond的例子，比如分配房间的例子在书中都有讲解，也挺好理解的，这里就不赘述了。

2.3.1 发送信号的方式：Signal和Broadcast

golang的runtime会内部维护一个FIFO的goroutine队列，等待接收信号。Signal会发现等待时间最长的goroutine并且通知它，而Broadcast会向所有等待的goroutine发送信号。

这里的Broadcast提供了一种同时和多个goroutine通信的方式，当然，我们也可以通过channel对信号进行简单的复制，但是使用Broadcast是更加自然且高效的行为。

2.4 once

once，顾名思义就是只执行一次。就很简单。就很简单。

function := func() {fmt.Println("Only do it once.")
}
var once sync.Once
var wg sync.WaitGroup
wg.Add(100)
for i:=0; i<100; i++ {defer wg.Done()once.Do(function)
}
wg.Wait()

直觉告诉我们这句话Only do it once.只会输出一次。事实上确实如此。

这里需要注意的一点是：once只记录自己一共执行了多少个函数，而并非多少个不同的函数。

2.5 Pool 池

Pool是Pool设计模式的并发安全实现。Pool设计模式是一种可以创建和提供可供使用的固定数量的实例或者Pool实例的方法。通常用于约束创建昂贵的场景（比如数据库的连接操作）。对于sync.Pool，这种数据类型可以被多个goroutine安全的使用。

Pool的主要的几个方法是：

使用Get方法来获取一个池中的实例给调用者。如果池中没有则会new一个新的实例出来。
在使用完毕之后，会调用Put方法把实例还给池。

2.5.1 为什么使用Pool？

为什么要使用Pool而不是直接创建一个新的实例呢？这是因为golang有GC，因此实例化的对象会被自动清理。

另一个原因是，可以使用Pool来尽可能快的将预先分配的对象缓存加载启动。在处理代价昂贵的事务的时候这种模式可以极大的提高性能。

当并发进程需要一个对象，并且处理它的过程会是相当的快速的过程，或者这些对象的构造过程会对内存产生负面的影响，这个时候你最好使用Pool设计模式。

使用Pool时最好注意的几个点：

当实例化sync.Pool时，使用new方法创建一个成员变量，在调用时会是线程安全的。
当你收到一个来自Get方法的实例的时候，不需要对接受的对象的状态进行任何的假设判定，因为一定合法的。
当你使用完成了一个从Pool中取出来的实例的时候，请一定使用Put方法把它放回去，负责你就没有办法复用这个实例了，通常情况之下会使用defer关键字来调用方法。

3. channel 信道

正如之前介绍过的CSP中的channel一样，你最好使用golang中的channel来进行goroutine之间的通信。而并非是用于同步内存访问。

channel是一个用于传递信息的管道。信息从一头进，从一头出。

3.1 创建和使用channel

创建一个channel非常的简单，只是需要指定一下数据的类型

var dataStream chan interface{} // 声明
dataStream = make(chan interface{}) // 实例化

一个普通的channel是双向的，也就是既可以输入数据，也可以读出数据。但是事实上，你也可以使用单向的channel，也就是定义一个channel，只用于发送或者接受数据。

var readStream <-chan interface{} // 一个只用于读取的channel
var inputStream chan<- interface{} // 一个只用于输入的channel

golang在必要的时候会将双向的channel隐式地转换为单向的channel。

一个简单的小例子：

stringStream := make(chan string)
go func() {stringStream <-"Hello, channels!"
}()
fmt.Println(<-stringStream)

这一段程序中，按照我们之前的理解：竞争条件在这里依然存在，也就是在程序退出之前很可能都不会执行goroutine中的内容。但是事实上channel消除了竞争条件。

这是因为channel的输入和读出在一定条件下都会让goroutine阻塞：当channel是空，但是你想要读取数据。或者channel满了你却想输入数据的时候。

能够阻塞，当然也能导致DeadLock，因此在使用的时候一定要注意。

关闭一个channel：

close(stringStream)

读出数据的时候可以读出两个值：

data, ok := <-stringStream
// 第一个值是数据值，或者被关闭的通道产生的数据的默认值
// 第二个值是状态值，判断信道的状态是开放还是关闭，开放是true，关闭是false

正因为channel的可以关闭并且有返回值的特性，我们可以使用for-range，并且在channel关闭的时候自动中断循环。

for data := range stringStream {}

3.2 带缓冲的信道 buffered channel

所谓buffered channel就是一个有缓冲容量的信道，我们在之前看到的channel其实就是缓冲容量为0的信道。我们在声明一个新的信道的时候就可以指定缓冲容量。

dataStream := make(chan interface{}, 4)

带缓冲的channel是一个内存中的FIFO队列，用于并发进程之间的通信。

两个比较生动形象的图：

3.3 channel上的操作和相应的结果

操作	Channel的状态	结果
Read	nil	阻塞
	打开且非空	输出值
	打开但是空	阻塞
	关闭	<默认值>，false
	只写	编译错误
Write	nil	阻塞
	打开且满	阻塞
	打开且不满	写入值
	关闭	panic
	只读	编译错误
close	nil	panic
	打开且非空	关闭channel；读取成功，直到信道内值耗尽，然后读取产生值的默认值
	打开但是空	关闭channel；读到生产者的默认值
	关闭的	panic
	只读	编译错误

3.4 使用channel的基本素养

所谓基本素养，其实就是规范使用channel的方法，从而规避死锁和panic的风险。

一个拥有channel的goroutine应该有以下操作：

1. 实例化channel
1. 执行写操作，或者将channel的所有权传递给其他goroutine
1. 关闭channel
1. 将1-3项封装好，并且通过一个只读channel将其暴露出来

4. select语句

channel是goroutine之间的粘合剂，而select语句则是channel之间的粘合剂。

如何使用select语句呢？下面是一个简单的示例：

var chan1, chan2 <-chan interface{}
var chan3 chan<- interface{}
select {case <-chan1:// ...
case <-chan2:// ...
case c3<- struct{}{}:// ...
}

和switch语句是很像，但是select语句中的case语句没有测试顺序，即使没有满足任何条件，执行也不会失败。而且一个很大的特性是：golang运行时会将一组case语句中执行伪随机选择。

使用伪随机选择的原因是，golang无法解析select语句的意图，也就是说，它不能推断出问题空间，或者说为什么将一组channel组合在一个select语句中。在这种情况下，最好的选择就是平均情况下运行良好。

4.1 为select语句设置超时时间

var channel <-chan int
select {case <-channel:
case <-time.After(1*time.Second):// ...超时操作
}

4.2 select语句中的default

在select中也存在default语句，执行的条件是全部的channel都是阻塞的。

var channel <-chan int
select {case <-channel:
default:// ...几乎是瞬间执行
}

4.3 使用for-select结构在等待同时工作

for {select {case channel:// ...default:}// ...工作语句
}

4.4 永远阻塞的语句也永远最简单

select{}

这个语句将永远阻塞