當我跟別人說我熱愛演算法與資料結構時，大家常常一臉困惑。大多數人都大概知道程式設計師在做什麼，卻不太清楚電腦科學到底有什麼用。就算知道，也覺得它沒有什麼實際的用途。讓我用一個簡單的例子來說明，應用電腦科學其實無所不在。

想像有一堆襪子等著你去分類。這絕對不是什麼令人興奮的消遣。你已經把這件事拖了很久，現在要完成恐怕得花上一小時。

衡量了一下你的選擇，你決定找人幫忙。你和朋友一起動手，大約只花了一半的時間就完成了。

電腦科學家可能會把這堆襪子稱為資源。而你和朋友則被毫不客氣地貶為工作者。你們兩人可以同時處理這個問題——也就是平行處理。這就是平行運算的核心概念。

而襪子分類之所以很適合拿來平行處理，是因為它具備一些特性。

• 工作可以被很好地拆分。對每個工作者來說，找到一雙襪子所需的時間都差不多。
• 找到不同的一雙襪子是完全獨立的工作，可以同時進行。

指派給這項任務的工作者越多，完成的速度就越快。

• 1 個工作者需要 60 分鐘。
• 2 個工作者需要 30 分鐘。

那 3 個工作者需要多久呢？沒錯！大約 20 分鐘。我們可以為這種關係寫下一個簡單的公式：

不過，這樣算並不完全正確。我們忘了考慮額外開銷：當 Mary 想拿起一隻襪子時，Stephen 可能也正好伸手要拿同一隻。他們相視一笑，其中一人就去拿另一隻襪子。在運算中，工作者也可能會做同樣的事。嗯，不會微笑啦，但會去找另一個工作來做。當許多工作者共享資源時，這種情況其實相當頻繁。而要處理這種狀況，總是得花上一點額外的時間。所以，也正因為如此，我們離理想的分類速度總是差了一點。

但情況還會更糟！假設你有 100 個工作者要處理 100 隻襪子。一開始，每個工作者可能都各拿起一隻襪子，試著找到與之配對的另一隻。問題來了：當每個人都各拿了一隻襪子後，就沒有襪子剩下了。所有工作者都陷入等待狀態。分類工作就永遠無法完成。這就是死結，也是平行運算中最令人害怕的情境之一。

在這種情況下，一個簡單的解法是把襪子放回去，等一段時間後再試著拿新的襪子。另一種擺脫困境的方法，則是強制執行某種分類的「協定」。你可以把協定想成是工作者之間為了達成共同目標而達成的默契。

所以，在我們的例子中，每個工作者可以只負責一種顏色的襪子。工作者一負責綠色襪子，工作者二負責灰色襪子，以此類推。透過這個簡單的技巧，我們就能避免死結，因為大家處理的是完全獨立的工作。

但還是有個問題。如果只有四隻綠色襪子，卻有 4000 隻灰色襪子呢？工作者一很快就會無聊透頂。他一下子就把兩雙襪子分好了，然後只能看著工作者二處理剩下的部分。這可不太有團隊精神，對吧？

像這樣拆分工作，只有在我們可以假設每種顏色的襪子數量都差不多時才最有意義。這樣才能讓每個人的工作量大致相當。

下面的長條圖可以讓你更清楚我的意思：

在這個例子中，每種顏色的襪子堆大小都差不多。對我來說，這看起來就是每個工作者工作量都很公平的情況。

在第二個例子中，分布並不平均。在這個例子裡，我可不想負責分灰色的襪子。我們得再多想一下。

那我們能怎麼做呢？

多數時候，換個方式拆分工作會有所幫助。舉例來說，我們可以讓兩個工作者一起整理那一大堆灰色襪子。一個負責大的襪子，另一個負責小的襪子。不過，我們又會遇到另一個問題：在這種情況下，誰來決定什麼叫「大」、什麼叫「小」呢？

所以，與其絞盡腦汁想出更聰明的方法，我們決定務實一點。每個人就各自抓起大小差不多的一堆襪子——不管顏色或尺寸——然後開始動手。

每一堆很可能都會剩下一些找不到配對的襪子。沒關係。我們只要把這些剩下的襪子全丟在一起，混一混，重新分成新的幾堆，再繼續分類。我們就這樣重複直到全部完成。我們把這叫做工作佇列。它有兩個好處：第一，你不需要工作者之間再有任何額外的協定；第二，它能隨著工作者數量的增加而合理地擴展，不需要對問題本身想得太複雜。

分散式系統棘手的地方在於，看似直截了當的解法在實務上可能會徹底失敗。

如果我們的小襪子堆看起來像這樣呢？

每一堆裡能配成對的數量……實在令人沮喪。我們可以做的是，先進行一個非常快速的預先分類步驟，來增加配對的數量。或者，也許你能想出更好的點子？
最酷的是，一旦你找到更快的方法，它也能套用到類似的工作上。

像這樣的問題，其根源都在電腦科學中，而且它們無所不在。我個人不太喜歡 Computer Science 這個詞。我比較喜歡德文的「Informatik」，我會把它大致翻譯為「資訊科學」。因為我們在這裡所做的真正本質，是要找到一個通用的方法，來解決一整類問題。我們思考的是物件的本質及其特性。我們不是在分襪子；我們試圖回答資訊的根本問題。或許現在你就能理解，為什麼我會對這個領域如此熱情。

對了，這裡還有一篇相關文章，談談我為什麼熱愛程式設計。