当我跟别人说起自己对算法和数据结构的热爱时，大家常常一脸困惑。多数人大概能理解程序员是做什么的，却不明白计算机科学到底有什么用。即便明白了，也觉得它没什么实际意义。让我用一个简单的例子来说明，应用层面的计算机科学其实无处不在。

想象一下有一大堆袜子等着整理。算不上什么令人兴奋的消遣。你把这事拖了太久，以至于真要做起来恐怕得花上一个小时。

权衡之后，你决定找人帮忙。你和一位朋友一起动手，大概只花了一半时间就完成了。

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

现在，整理袜子这件事有些特性，让它很适合并行处理。

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

分配的工人越多，完成得就越快。

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

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

不过，这么算并不完全准确。我们忘了考虑开销：当玛丽想拿起一只袜子时，斯蒂芬可能正好也伸手去拿同一只。两人相视一笑，其中一人便去拿另一只。在计算中，工人也会遇到同样的情况。只不过不会相视一笑，而是去领取另一个任务。当大量工人共享资源时，这种情况会频繁发生。而每次化解都需要一点额外的时间。因此，受此影响，我们离理想的整理速度总会差一点。

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

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

那么在我们这个例子里，每个工人可以只负责一种颜色的袜子。工人一负责绿色，工人二负责灰色，以此类推。用这个简单的小技巧，我们就能避免死锁，因为大家处理的是完全独立的任务。

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

像这样分工，只有当每种颜色的袜子数量大致相当时才最合理。这样才能让每个人的工作量基本均衡。

下面的直方图能让你直观感受到我的意思：

在这种情况下，每种颜色的袜子堆大小都差不多。在我看来，每个工人的工作量都很公平。

第二种情况则分布不均。就这个例子而言，我可不想去整理那堆灰袜子。这里我们得再多动动脑筋。

那该怎么办呢？

大多数时候，换一种拆分工作的方式会有所帮助。比如，我们可以让两个工人一起整理那一大堆灰袜子。一个负责整理大号的，另一个负责整理小号的。不过，这里又冒出一个新问题：谁来决定在这个场景下什么算“大”、什么算“小”呢？

所以，与其绞尽脑汁去想更聪明的办法，我们决定务实一点。每个人直接抓起一堆数量相当的袜子——不管颜色或大小——然后开工。

很可能，每堆里都会剩下一些找不到配对的袜子。没关系。我们把它们全部丢到一起，混匀后重新分成几堆，再继续整理。如此反复，直到全部完成。我们把这叫做任务队列。它有两个好处：第一，工人之间不需要额外的约定；第二，它能随着工人数量的增加而相对良好地扩展，而无需对问题本身想得过于复杂。

分布式系统的棘手之处在于，那些看似直截了当的解决方案在实践中可能会彻底失败。

如果我们分好的小堆看起来像这样呢？

每堆里能配成对的数量……实在令人沮丧。我们可以先做一个非常快速的预排序步骤来提高配对数。或者，也许你能想出更棒的主意？
妙处在于，一旦你找到了更快的方法，它同样适用于类似的任务。

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

对了，这里还有一篇相关文章，聊的是我为什么热爱编程。