概述
并发编程是个很大的论题。但限于篇幅，这里仅讨论一些Go特有的东西。
在并发编程中，为实现对共享变量的正确访问需要精确的控制，这在多数环境下都很困难。 Go语言另辟蹊径，它将共享的值通过信道传递，实际上，多个独立执行的 线程 从不会主动共享。 在任意给定的时间点，只有一个Go程能够访问该值。数据竞争从设计上就被杜绝了。 为了提倡这种思考方式，我们将它简化为一句口号：
这种方法意义深远。例如，引用计数通过为整数变量添加互斥锁来很好地实现。 但作为一种高级方法，通过信道来控制访问能够让你写出更简洁，正确的程序。
我们可以从典型的单线程运行在单CPU之上的情形来审视这种模型。它无需提供同步原语。 现在考虑另一种情况，它也无需同步。现在让它们俩进行通信。若将通信过程看做同步着， 那就完全不需要其它同步了。例如，Unix管道就与这种模型完美契合。 尽管Go的并发处理方式来源于Hoare的通信顺序处理（CSP）， 它依然可以看做是类型安全的Unix管道的实现。
goroutine
我们称之为Go程是因为现有的术语—线程、协程、进程等等—无法准确传达它的含义。 Go程具有简单的模型：它是与其它Go程并发运行在同一地址空间的函数。它是轻量级的， 所有小号几乎就只有栈空间的分配。而且栈最开始是非常小的，所以它们很廉价， 仅在需要时才会随着堆空间的分配（和释放）而变化。
Go程在多线程操作系统上可实现多路复用，因此若一个线程阻塞，比如说等待I/O， 那么其它的线程就会运行。Go程的设计隐藏了线程创建和管理的诸多复杂性。
在函数或方法前添加 go 关键字能够在新的Go程中调用它。当调用完成后， 该Go程也会安静地退出。（效果有点像Unix Shell中的 & 符号，它能让命令在后台运行。）
golist.Sort() // 并发运行 list.Sort，无需等它结束。
函数字面在Go程调用中非常有用。
funcAnnounce(messagestring, delaytime.Duration) {
gofunc() {
time.Sleep(delay)
fmt.Println(message)
}() // 注意括号 - 必须调用该函数。
}
在Go中，函数字面都是 闭包 ：其实现在保证了函数内引用变量的生命周期与函数的活动时间相同。
这些函数没什么实用性，因为它们没有实现完成时的信号处理。因此，我们需要信道。
channel(信道)
信道与map一样，也需要通过 make 来分配内存。其结果值充当了对底层数据结构的引用。 若提供了一个可选的整数形参，它就会为该信道设置缓冲区大小。默认值是零，表示不带缓冲的或同步的信道。
ci:=make(chanint) // 整数类型的无缓冲信道 cj:=make(chanint, 0) // 整数类型的无缓冲信道 cs:=make(chan*os.File, 100) // 指向文件指针的带缓冲信道
无缓冲信道在通信时会同步交换数据，它能确保（两个Go程的）计算处于确定状态。
信道有很多惯用法，我们从这里开始了解。在上一节中，我们在后台启动了排序操作。 信道使得启动的Go程等待排序完成。
c:=make(chanint) // 分配一个信道
// 在Go程中启动排序。当它完成后，在信道上发送信号。
gofunc() {
list.Sort()
c<-1 // 发送信号，什么值无所谓。
}()
doSomethingForAWhile()
<-c // 等待排序结束，丢弃发来的值。
接收者在收到数据前会一直阻塞。若信道是不带缓冲的，那么在接收者收到值前， 发送者会一直阻塞；若信道是带缓冲的，则发送者仅在值被复制到缓冲区前阻塞； 若缓冲区已满，发送者会一直等待直到某个接收者取出一个值为止。
带缓冲的信道可被用作信号量，例如限制吞吐量。在此例中，进入的请求会被传递给 handle，它从信道中接收值，处理请求后将值发回该信道中，以便让该 “信号量”准备迎接下一次请求。信道缓冲区的容量决定了同时调用 process 的数量上限，因此我们在初始化时首先要填充至它的容量上限。
varsem=make(chanint, MaxOutstanding)
funchandle(r* Request ) {
sem<-1// 等待活动队列清空。
process(r) // 可能需要很长时间。
<-sem // 完成；使下一个请求可以运行。
}
funcServe(queuechan*Request) {
for{
req:=<-queue
gohandle(req) // 无需等待 handle 结束。
}
}
由于数据同步发生在信道的接收端，因此信号必须在信道的接收端获取，而非发送端。
然而，它却有个设计问题：尽管只有 MaxOutstanding 个Go程能同时运行，但 Serve 还是为每个进入的请求都创建了新的Go程。其结果就是，若请求来得很快， 该程序就会无限地消耗资源。为了弥补这种不足，我们可以通过修改 Serve 来限制创建Go程，这是个明显的解决方案，但要当心我们修复后出现的Bug。
funcServe(queuechan*Request) {
forreq:=rangequeue{
sem<-1
gofunc() {
process(req) // 这儿有Bug，解释见下。
<-sem
}()
}
}
Bug出现在Go的 for 循环中，该循环变量在每次迭代时会被重用，因此 req 变量会在所有的Go程间共享，这不是我们想要的。我们需要确保 req 对于每个Go程来说都是唯一的。有一种方法能够做到，就是将 req 的值作为实参传入到该Go程的闭包中：
funcServe(queuechan*Request) {
forreq:=rangequeue{
sem<-1
gofunc(req*Request) {
process(req)
<-sem
}(req)
}
}
比较前后两个版本，观察该闭包声明和运行中的差别。 另一种解决方案就是以相同的名字创建新的变量，如例中所示：
funcServe(queuechan*Request) {
forreq:=rangequeue{
req:=req// 为该Go程创建 req 的新实例。
sem<-1
gofunc() {
process(req)
<-sem
}()
}
}
它的写法看起来有点奇怪
req:=req
但在Go中这样做是合法且惯用的。你用相同的名字获得了该变量的一个新的版本， 以此来局部地刻意屏蔽循环变量，使它对每个Go程保持唯一。
回到编写服务器的一般问题上来。另一种管理资源的好方法就是启动固定数量的 handle Go程，一起从请求信道中读取数据。Go程的数量限制了同时调用 process 的数量。Serve 同样会接收一个通知退出的信道， 在启动所有Go程后，它将阻塞并暂停从信道中接收消息。
funchandle(queuechan*Request) {
forr:=rangequeue{
process(r)
}
}
funcServe(clientRequestschan*Request, quitchanbool) {
// 启动处理程序
fori:=0; i<MaxOutstanding; i++{
gohandle(clientRequests)
}
<-quit // 等待通知退出。
}
信道中的信道
Go最重要的特性就是信道是一等值，它可以被分配并像其它值到处传递。 这种特性通常被用来实现安全、并行的多路分解。
在上一节的例子中，handle 是个非常理想化的请求处理程序， 但我们并未定义它所处理的请求类型。若该类型包含一个可用于回复的信道， 那么每一个客户端都能为其回应提供自己的路径。以下为 Request 类型的大概定义。
typeRequeststruct{
args []int
f func([]int) int
resultChan chanint
}
客户端提供了一个函数及其实参，此外在请求对象中还有个接收应答的信道。
funcsum(a[]int) (sint) {
for_, v:=rangea{
s+=v
}
return
}
request:=&Request{[]int{3, 4, 5}, sum, make(chanint)}
// 发送请求
clientRequests<-request
// 等待回应
fmt.Printf("answer: %d\n", <-request.resultChan)
funchandle(queuechan*Request) {
forreq:=rangequeue{
req.resultChan<-req.f(req.args)
}
}
要使其实际可用还有很多工作要做，这些代码仅能实现一个速率有限、并行、非阻塞RPC系统的 框架，而且它并不包含互斥锁。
并行化
这些设计的另一个应用是在多CPU核心上实现并行计算。如果计算过程能够被分为几块 可独立执行的过程，它就可以在每块计算结束时向信道发送信号，从而实现并行处理。
让我们看看这个理想化的例子。我们在对一系列向量项进行极耗资源的操作， 而每个项的值计算是完全独立的。
typeVector[]float64
// 将此操应用至 v[i], v[i+1] ... 直到 v[n-1]
func(vVector) DoSome(i, nint, uVector, cchanint) {
for; i<n; i++{
v[i] +=u.Op(v[i])
}
c<-1 // 发信号表示这一块计算完成。
}
我们在循环中启动了独立的处理块，每个CPU将执行一个处理。 它们有可能以乱序的形式完成并结束，但这没有关系； 我们只需在所有Go程开始后接收，并统计信道中的完成信号即可。
constNCPU=4 // CPU核心数
func(vVector) DoAll(uVector) {
c:=make(chanint, NCPU) // 缓冲区是可选的，但明显用上更好
fori:=0; i<NCPU; i++{
gov.DoSome(i*len(v)/NCPU, (i+1)*len(v)/NCPU, u, c)
}
// 排空信道。
fori:=0; i<NCPU; i++{
<-c // 等待任务完成
}
// 一切完成。
}
在go1.5之前，Go运行时的实现默认并不会并行执行代码，它只为用户层代码提供单一的处理核心。 任意数量的Go程都可能在系统调用中被阻塞，而在任意时刻默认只有一个会执行用户层代码。 它应当变得更智能，而且它将来肯定会变得更智能。但现在，若你希望CPU并行执行， 就必须告诉运行时你希望同时有多少Go程能执行代码。有两种途径可意识形态，要么 在运行你的工作时将 GOMAXPROCS 环境变量设为你要使用的核心数， 要么导入 runtime 包并调用 runtime.GOMAXPROCS(NCPU)。 runtime.NumCPU() 的值可能很有用，它会返回当前机器的逻辑CPU核心数。在go1.5之后的版本默认已经是多核处理了。
可能泄露的缓冲区
并发编程的工具甚至能很容易地表达非并发的思想。这里有个提取自RPC包的例子。 客户端Go程从某些来源，可能是网络中循环接收数据。为避免分配和释放缓冲区， 它保存了一个空闲链表，使用一个带缓冲信道表示。若信道为空，就会分配新的缓冲区。 一旦消息缓冲区就绪，它将通过 serverChan 被发送到服务器。 serverChan.
varfreeList=make(chan* Buffer , 100)
varserverChan=make(chan*Buffer)
funcclient() {
for{
varb*Buffer
// 若缓冲区可用就用它，不可用就分配个新的。
select{
caseb=<-freeList:
// 获取一个，不做别的。
default:
// 非空闲，因此分配一个新的。
b=new(Buffer)
}
load(b) // 从网络中读取下一条消息。
serverChan<-b // 发送至服务器。
}
}
服务器从客户端循环接收每个消息，处理它们，并将缓冲区返回给空闲列表。
funcserver() {
for{
b:=<-serverChan // 等待工作。
process(b)
// 若缓冲区有空间就重用它。
select{
casefreeList<-b:
// 将缓冲区放大空闲列表中，不做别的。
default:
// 空闲列表已满，保持就好。
}
}
}
客户端试图从 freeList 中获取缓冲区；若没有缓冲区可用， 它就将分配一个新的。服务器将 b 放回空闲列表 freeList 中直到列表已满，此时缓冲区将被丢弃，并被垃圾回收器回收。（select 语句中的 default 子句在没有条件符合时执行，这也就意味着selects 永远不会被阻塞。）依靠带缓冲的信道和垃圾回收器的记录， 我们仅用短短几行代码就构建了一个可能导致缓冲区槽位泄露的空闲列表。
