《实战 Java 高并发程序设计》笔记——第1章 走入并行世界（一）

声明：

本博客是本人在学习《实战 Java 高并发程序设计》后整理的笔记，旨在方便复习和回顾，并非用作商业用途。

本博客已标明出处，如有侵权请告知，马上删除。

当你打开本书，也许你正试图将你的应用改造成并行模式运行，也许你只是单纯地对并行程序感兴趣。无论出于何种原因，你正对并行计算充满好奇、疑问和求知欲。如果是这样，那就对了，带着你的好奇和疑问，让我们一起遨游并行程序的世界，深入了解它们究竟是如何工作的吧！

不过首先，我想要公布一条令人沮丧的消息。就在大伙儿都认为并行计算必然成为未来的大趋势时，2014 年底，Avoiding ping pong 论坛上，伟大的 Linus Torvalds 提出了一个截然不同的观点，他说：“忘掉那该死的并行吧！”（原文：Give it up.The whole “parallel computing is the future” is a bunch of crock.）

1.1 何去何从的并行计算

到底我们该如何选择呢？本节的目的就是拨云见日。

1.1.1 忘掉那该死的并行

Linus Torvalds 是一个传奇式的人物，是他给出了 Linux 的原型，并一直致力于推广和发展 Linux 系统。他在 1991 年首先在网络上发布了 Linux 源码，从此一发而不可收。Linux 迅速崛起壮大，成为目前使用最广泛的操作系统之一。

自 2002 年起，Linus 就决定使用 BitKeeper 作为 Linux 内核开发的版本控制工具，以此来维护 Linux 的内核源码。BitKeeper 是一套分布式版本控制软件，它是一套商用系统，由 BitMover 公司开发。2005 年，BitKeeper 宣称发现 Linux 内核开发人员使用逆向工程来试图解析 BitKeeper 内部协议。因此，决定向 Linus 收回 BitKeeper 授权。尽管 Linux 核心团队与 BitMover 公司进行了协商，但是无法解决他们之间的分歧。因此，Linus 决定自行研发版本控制工具来代替 BitKeeper。于是，Git 诞生了。

如果大家正在使用 Git，我相信你们一定会被 Git 的魅力所折服，如果还没有了解过 Git，那么我强烈建议你去关注一下这款优秀的产品。

而正是这位传奇人物，给目前红红火火的并行计算泼了一大盆冷水。那么，并行计算究竟应该何去何从呢？

在 Linus 的发言中这么说道：

Where the hell do you envision that those magical parallel algorithms would be used?

The only place where parallelism matters is in graphics or on the server side，where we already largely have it.Pushing it anywhere else is just pointless.

需要有多么奇葩的想象力才能想象出并行计算的用武之地？

并行计算只有在图像处理和服务端编程 2 个领域可以使用，并且它在这 2 个领域确实有着大量广泛的使用。但是在其他任何地方，并行计算毫无建树！

So the whole argument that people should parallelize their code is fundamentally flawed.It rests on incorrect assumptions.It’s a fad that has been going on too long.

因此，人们在争论是否应该将他们的代码并行化是一个本质上的错误。这完全就基于一个错误的假设。“并行” 是一个早该结束的时髦用语。

看了这段较为完整的表述，大家应该对 Linus 的观点有所感触，我对此也表示赞同。与串行程序不同，并行程序的设计和实现异常复杂，不仅仅体现在程序的功能分离上，多线程间的协调性、乱序性都会成为程序正确执行的障碍。只要你稍不留神，就会失之毫厘，谬以千里！混乱的程序难以阅读、难以理解，更难以调试。所谓并行，也就是把简单问题复杂化的典型。因此，只有 “疯子” 才会叫嚣并行就是未来（the crazies talking about scaling to hundreds of cores are just that-crazy）。

但是，Linus 也提出了两个特例，那就是图像处理和服务端程序是可以、也需要使用并行技术的。仔细想想，为什么图像处理和服务端程序是特例呢？

和用户终端程序不同，图像处理往往拥有极大的计算量。一张 1024×768 像素的图片，包含多达 78 万 6 千多个像素。即使将所有的像素遍历一遍，也得花不少时间。更何况，图像处理涉及大量的矩阵计算。矩阵的规模和数量都会非常大。面对如此密集的计算，很有可能超过单核 CPU 的计算能力，所以自然需要引入多核计算了。

而服务端程序与一般的用户终端程序相比，一方面，服务端程序需要承受很重的用户访问压力。根据淘宝的数据，它在 “双十一” 一天，支付宝核心数据库集群处理了 41 亿个事务，执行 285 亿次 SQL，生成 15TB 日志，访问 1931 亿次内存数据块，13 亿个物理读。如此密集的访问，恐怕任何一台单机都难以胜任，因此，并行程序也就自然成了唯一的出路。另一方面，服务端程序往往会比用户终端程序拥有更复杂的业务模型。面对复杂业务模型，并行程序会比串行程序更容易适应业务需求，更容易模拟我们的现实世界。毕竟，我们的世界本质上是并行的。比如，当你开开心心去上学的时候，妈妈可能在家里忙着家务，爸爸在外打工赚钱，一家人其乐融融。如果有一天，你需要使用你的计算机来模拟这个场景，你会怎么做呢？如果你就在一个线程里，既做了你自己&#