并发不是并行 它更好！

现代社会是并行的：多核、网络、云计算、用户负载，并发技术对此有用。

Go语言支持并发，它提供了：并发执行（goroutines），同步和消息（channels）和多路并发控制（select）。

当Go声称是并发时，人们说：“并发很酷！耶，我可以并行运行了！”，但这是个错误的。因为很多人都不了解他们间的差别。“我用四个处理器来做质数筛选，但是更慢了。”

并发(Concurrency)：

以可独立执行的进程集合的方式编程（进程是出了名的难定义，这里是通常意义上的进程，不是Linux进程）

并行(Parallelism)：

以可同时执行的（可能相关的）计算指令方式编程。

两者的区别：

并发是同时处理(dealing)很多的事情，并行是同时做(doing)很多的事情。不同，但也相关。一个是关于代码结构，一个是关于代码执行。并发为可能的（不是必须的）并行问题提供了一种解决方案。

一个类比：

鼠标、键盘、显示器、磁盘驱动是并发结构的。向量点积是并行的。

并发带有通信：

并发是一种构造程序的方式，把任务分解为一个个独立运行的小任务。通信是协调这些小任务的手段。

Go的模型（还有Erlang等）都是基于CPS(Communicatingsequential processes, 通信顺序进程)：其论文C. A. R. Hoare: Communicating SequentialProcesses (CACM 1978)

 

以上讲得太抽象了，我们举实际点的例子。

 

我们的问题：把一堆废弃语言的说明书运到火炉里，一只地鼠会花费很长时间。

更多的地鼠

单单更多的地鼠也不解决问题，它们需要更多的推车。

更多的地鼠、更多的推车

这样会加快速度，但它们会在那堆书和炉子那边遇上瓶颈。同时也要同步两只地鼠，可以通过消息的方式实现。

全部加倍

这样会以两倍的速度运送。这是两个地鼠程序的并发构成（concurrentcomposition）。

但这种设计不是自发并行的，如果一次只有一只地鼠在运会怎样？

这种设计仍是并发，不是并行。[译者注：一只地鼠运一次上面那堆书，然后第二只地鼠再运一次下面那堆书。一次只允许一只地鼠运送，这样就不是并行的。

然而，这种场景是可以自发并行的。并发构成可以考虑下其他模型。

另一种设计

三只地鼠在工作，但可能会有延误。每只地鼠是个独立的步骤，附加协调（通信）。

更细粒度的并发

增加一只地鼠用来运回空推车。四只地鼠在工作，运行得更加流畅，每只地鼠都在做一个简单的任务。

如果我们把事情安排的足够好（现实中很难但不是不可能），速度会是最先只有一只地鼠的那个设计的四倍。

观察结论：我们在一个已有的设计（指三个地鼠的那个设计）中添加一个并发的步骤（第四只地鼠）增强了系统的性能。更多的地鼠干了更多的活，系统运行得更好。并发比简单的并行对问题要有更深的洞察。

我们有四个并发的步骤：1.装书到推车上2.把推车运到火炉边3.把书卸到火炉里4.运回空推车

不同的并发设计能以不同的方式来并行。

更多的并行

我们以另一个维度来并行，并行使这样的设计变的容易。八只地鼠，都在繁忙工作。

但也可能根本没有并行

谨记：即使一次只能有一只地鼠在工作（零并行），这也不失为一个良好的并发的解决方案。

另一种设计

下面也是一种用并发组成来解决问题的设计。两只地鼠，再加上一个中转堆。

以一般的方式来并行

用更多的并发程序来提高吞吐量

或者一种不同的方式

在多地鼠并发模型中引入中转堆

全面优化

使用我们所有的技术，16只地鼠都开足马力。

学到内容

我们有很多方法把问题分解，这才是并发设计。一旦我们分解了问题，并行就自然而然的产生了，正确性也变得很容易。

回到计算

我们关于运书的问题，可以看做是如下的类比：书堆是Web数据，地鼠是CPU，推车是调度、渲染或是网络，火堆是代理、浏览器或是其他的消费者。地鼠提供网络数据，这就是一个可扩展的Web服务的并发设计了。

原文Html5编写：http://concur.rspace.googlecode.com/hg/talk/concur.html