<!-- The Terminology Problem --> ## 术语问题 术语“并发”，“并行”，“多任务”，“多处理”，“多线程”，分布式系统（可能还有其他）在整个编程文献中都以多种相互冲突的方式使用，并且经常被混为一谈。 *Brian Goetz* 在他 2016 年《从并发到并行》的演讲中指出了这一点，之后提出了合理的二分法： - 并发是关于正确有效地控制对共享资源的访问。 - 并行是使用额外的资源来更快地产生结果。 这些定义很好，但是我们已有几十年混乱使用和抗拒解决此问题的历史了。一般来说，当人们使用“并发”这个词时，他们的意思是“所有的一切”。事实上，我自己也经常陷入这样的想法。在大多数书籍中，包括 *Brian Goetz* 的 《Java Concurrency in Practice》，都在标题中使用这个词。 “并发”通常表示：不止一个任务正在执行。而“并行”几乎总是代表：不止一个任务同时执行。现在你能看到问题所在了吗？“并行”也有不止一个任务正在执行的语义在里面。区别就在于细节：究竟是怎么“执行”的。此外，还有一些场景重叠：为并行编写的程序有时在单处理器上运行，而一些并发编程系统可以利用多处理器。 还有另一种方法，在减速发生的地方写下定义（原文Here’s another approach, writing the definitions around where the slowdown occurs）： **并发** 同时完成多任务。无需等待当前任务完成即可执行其他任务。“并发”解决了程序因外部控制而无法进一步执行的阻塞问题。最常见的例子就是 I/O 操作，任务必须等待数据输入（在一些例子中也称阻塞）。这个问题常见于 I/O 密集型任务。 **并行** 同时在多个位置完成多任务。这解决了所谓的 CPU 密集型问题：将程序分为多部分，在多个处理器上同时处理不同部分来加快程序执行效率。 上面的定义说明了这两个术语令人困惑的原因：两者的核心都是“同时完成多个任务”，不过并行增加了跨多个处理器的分布。更重要的是，它们可以解决不同类型的问题：并行可能对解决I / O密集型问题没有任何好处，因为问题不在于程序的整体执行速度，而在于I/O阻塞。而尝试在单个处理器上使用并发来解决计算密集型问题也可能是浪费时间。两种方法都试图在更短的时间内完成更多工作，但是它们实现加速的方式有所不同，这取决于问题施加的约束。 这两个概念混合在一起的一个主要原因是包括Java在内的许多编程语言使用相同的机制 - **线程**来实现并发和并行。 我们甚至可以尝试以更细的粒度去进行定义（然而这并不是标准化的术语）： - **纯并发**：仍然在单个CPU上运行任务。纯并发系统比顺序系统更快地产生结果，但是它的运行速度不会因为处理器的增加而变得更快。 - **并发-并行**：使用并发技术，结果程序可以利用更多处理器更快地产生结果。 - **并行-并发**：使用并行编程技术编写，如果只有一个处理器，结果程序仍然可以运行（Java 8 **Streams**就是一个很好的例子）。 - **纯并行**：除非有多个处理器，否则不会运行。 在某些情况下，这可能是一个有用的分类法。 支持并发性的语言和库似乎是[抽象泄露（Leaky Abstraction）](https://en.wikipedia.org/wiki/Leaky_abstraction)一词的完美候选。抽象的目标是“抽象出”那些对于手头想法不重要的东西，以屏蔽不必要的细节。如果抽象是有漏洞的，那些碎片和细节就会不断重新声明自己是重要的，无论你废了多少功夫来隐藏它们。 我开始怀疑是否真的有高度抽象。因为当编写这类程序时，底层的系统、工具，甚至是关于CPU缓存如何工作的细节，都永远不会被屏蔽。最后，如果你非常小心，你创作的东西在特定的情况下工作，但在其他情况下不工作。有时是两台机器的配置方式不同，有时是程序的估计负载不同。这不是Java特有的 - 这是并发和并行编程的本质。 你可能会认为[纯函数式](https://en.wikipedia.org/wiki/Purely_functional)语言没有这些限制。实际上，纯函数式语言解决了大量并发问题，所以如果你正在解决一个困难的并发问题，你可以考虑用纯函数语言编写这个部分。但最终，如果你编写一个使用队列的系统，例如，如果该系统没有被正确地调整，并且输入速率也没有被正确地估计或限制（在不同的情况下，限制意味着具有不同的影响的不同东西），该队列要么被填满并阻塞，要么溢出。最后，你必须了解所有细节，任何问题都可能会破坏你的系统。这是一种非常不同的编程方式。