当我向人们讲述我对算法和数据结构的热情时，他们总是露出困惑的表情。大多数人明白程序员是做什么的，却不明白计算机科学有什么用。即使明白，他们也认为它没有实际意义。让我用一个简单的例子来说明，应用计算机科学无处不在。

想象一下有一堆需要整理的袜子。这可不是什么令人兴奋的消遣。你把这项任务拖了太久，以至于现在不可避免地要花一个小时才能完成。

权衡之后，你决定找些帮手。你和一位朋友一起投入工作，你们大约只用了一半的时间就完成了。

计算机科学家可能会把这堆袜子称为资源。你和你的朋友则被毫不客气地降格为工人。你们俩可以同时处理这个问题——也就是并行地工作。这就是 Parallel Computing(并行计算) 的核心思想。

现在，整理袜子之所以适合并行完成，是因为它具备一些特性。

• 工作可以很好地分割。每个工人找到一双袜子所需的时间大致相同。
• 寻找另一双袜子是完全独立的任务，可以同时进行。

分配给这项任务的工人越多，完成得就越快。

• 1 个工人需要 60 分钟。
• 2 个工人需要 30 分钟。

那么 3 个工人需要多久呢？没错！大约 20 分钟。我们可以为这种关系写下一个简单的公式：

嗯，这样还不完全正确。我们忘了考虑overhead(开销)：当 Mary（玛丽）想拿起一只袜子时，Stephen（斯蒂芬）可能也伸手去拿同一只。两人相视一笑，其中一人拿起了另一只袜子。在计算中，工人也可能做同样的事。嗯，不会微笑，但会去拿另一个任务。当许多工人共享资源时，这种情况会相当频繁地发生。而解决这种状况总是需要一点额外的时间。所以正因为如此，我们离最理想的整理速度还有一点差距。

但情况还会更糟！假设你有 100 个工人要整理 100 只袜子。刚开始，每个工人可能各拿一只袜子并试图找到与之配对的另一只。问题来了：一旦每个工人各拿一只袜子，就没有袜子剩下。所有工人都处于等待状态。整理工作永远也无法完成。这就是deadlock(死锁)，也是并行计算中最可怕的场景之一。

在这种情况下，一个简单的解决方法是把袜子放回去，等待一段时间后再尝试拿新的袜子。另一种摆脱困境的办法是，强制执行某种整理“协议”。可以把协议看作是工人之间为实现共同目标而达成的默契。

所以，在我们的例子中，每个工人可能只负责一种颜色的袜子。工人一负责绿色袜子，工人二负责灰色袜子，以此类推。通过这个简单的技巧，我们可以避免死锁，因为我们在处理完全独立的任务。

但仍然有一个问题。如果只有四只绿色袜子，却有 4000 只灰色袜子呢？工人一很快就会无所事事。他转眼间就能整理好两双袜子，然后看着工人二整理剩下的所有袜子。这可算不上什么团队精神，对吧？

像这样分割工作，只有在我们可以假定每种颜色的袜子数量都大致相当时才最有意义。这样才能让每个人的工作量大致相同。

下面的直方图可以让你明白我的意思：

在这种情况下，每种颜色的袜子堆大小都大致相等。在我看来，这对每个工人来说都是公平的工作量。

在第二种情况下，分布并不均匀。在这个例子中，我可不想去整理灰色的袜子。我们需要再多动动脑筋。

我们能做什么呢？

大多数时候，思考其他分割工作的方式会有所帮助。例如，我们可以让两个工人一起整理那一大堆灰色袜子。一个负责整理大号袜子，另一个负责小号袜子。不过，我们又遇到了另一个问题：在这种情况下，谁来决定什么是“大号”、什么是“小号”呢？

所以，与其绞尽脑汁去想一个更巧妙的方法，不如在这里务实一点。每个人直接拿走大小相等的一堆袜子——不管颜色或大小——然后开始工作。

很可能，每堆袜子里都会剩下一些找不到配对的袜子。没关系。我们只需把它们全部扔到一起，混在一起，重新分成新的堆，再次整理。我们一直这样做，直到全部完成。我们把这叫做 task queue(任务队列)。它有两个优点：第一，你不需要工人之间进行额外的约定；第二，它能在不深入思考问题领域的情况下，随着工人数量的增加而相对良好地扩展。

分布式系统的棘手之处在于，看似简单直接的解决方案在实践中可能会彻底失败。

如果我们的小袜子堆看起来像这样，会怎么样呢？

每堆中的配对数量……令人沮丧。我们可以做的是运行一个非常快速的预分类步骤来增加配对的数量。或者，也许你能想出一个更好的主意？
最酷的是，一旦你找到了一种更快的方法，它也适用于类似的任务。

这类问题的根源在于计算机科学，而且它们无处不在。就我个人而言，我不太喜欢“Computer Science”这个词。我更喜欢德语中的“Informatik”，我会把它大致翻译为“信息科学”。因为我们在这里所做之事的真正本质，是找到一种通用的方法来解决一整类问题。我们思考对象的本质及其属性。我们不是在整理袜子；我们试图回答关于信息的基本问题。也许现在你能理解我为什么对这个学科如此热情了。

哦，顺便，这里还有一篇关于我为什么热爱编程的相关文章。