<!-- Concurrency Superpowers --> ## 并發的超能力 想象一下，你置身于一部科幻電影。你必須在高層建筑中搜索一個精心巧妙地隱藏在建筑物的一千萬個房間之一中的單個物品。你進入建筑物并沿著走廊向下移動。走廊分開了。 你自己完成這項任務需要一百個生命周期。 現在假設你有一個奇怪的超能力。你可以將自己一分為二，然后在繼續前進的同時將另一半送到另一個走廊。每當你在走廊或樓梯上遇到分隔到下一層時，你都會重復這個分裂的技巧。最終，整個建筑中的每個走廊的終點都有一個你。 每個走廊都有一千個房間。你的超能力變得有點弱，所以你只能分裂出50個自己來搜索這間房間。 一旦克隆體進入房間，它必須搜索房間的每個角落。這時它切換到了第二種超能力。它分裂成了一百萬個納米機器人，每個機器人都會飛到或爬到房間里一些看不見的地方。你不需要了解這種功能 - 一旦你開啟它就會自動工作。在他們自己的控制下，納米機器人開始行動，搜索房間然后回來重新組裝成你，突然間，你獲得了尋找的物品是否在房間內的消息。 我很想說，“并發就是剛才描述的置身于科幻電影中的超能力“就像你自己可以一分為二然后解決更多的問題一樣簡單。但是問題在于，我們來描述這種現象的任何模型最終都是泄漏抽象的（leaky abstraction)。 以下是其中一個漏洞：在理想的世界中，每次克隆自己時，你還會復制硬件處理器來運行該克隆。但當然不會發生這種情況 - 你的機器上可能有四個或八個處理器（通常在寫入時）。你可能還有更多，并且仍有許多情況只有一個處理器。在抽象的討論中，物理處理器的分配方式不僅可以泄漏，甚至可以支配你的決策 讓我們在科幻電影中改變一些東西。現在當每個克隆搜索者最終到達一扇門時，他們必須敲門并等到有人回答。如果我們每個搜索者有一個處理器，這沒有問題 - 處理器只是空閑，直到門被回答。但是如果我們只有8個處理器和數千個搜索者，我們不希望處理器僅僅因為某個搜索者恰好在等待回答中被鎖住而閑置下來。相反，我們希望將處理器應用于可以真正執行工作的搜索者身上，因此需要將處理器從一個任務切換到另一個任務的機制。 許多模型能夠有效地隱藏處理器的數量，并允許你假裝你的數量非常大。但是有些情況會發生故障的時候，你必須知道處理器的數量，以便你可以解決這個問題。 其中一個最大的影響取決于你是單個處理器還是多個處理器。如果你只有一個處理器，那么任務切換的成本也由該處理器承擔，將并發技術應用于你的系統會使它運行得更慢。 這可能會讓你認為，在單個處理器的情況下，編寫并發代碼時沒有意義。然而，有些情況下，并發模型會產生更簡單的代碼，實際上為了這個目的值得讓它運行得更慢。 在克隆體敲門等待的情況下，即使單處理器系統也能從并發中受益，因為它可以從等待（阻塞）的任務切換到準備好的任務。但是如果所有任務都可以一直運行那么切換的成本反而會使任務變慢，在這種情況下，如果你有多個進程，并發通常只會有意義。 假設你正在嘗試破解某種密碼，在同一時間內參與破解的線程越多，你越快得到答案的可能性就越大。每個線程都能持續使用你所分配的處理器時間，在這種情況下（一個計算約束問題），你的代碼中分配的線程數應該和你擁有的處理器的數量保持一致。 在接聽電話的客戶服務部門，你只有一定數量的員工，但是你的部門可能會收到很多電話。這些員工（處理器）一次只能處理一個電話，直到完成，與此同時，額外的電話必須排隊。 在“鞋匠和精靈”的童話故事中，鞋匠有很多工作要做，當他睡著時，出現了一群精靈來為他制作鞋子。這里的工作是分布式的，但即使使用大量的物理處理器，在制造鞋子的某些部件時也會產生限制 - 例如，鞋底需要大量的時間去制作，這會限制制鞋的速度并改變你設計解決方案的方式。 因此，你嘗試解決的問題驅動解決方案的設計。有一個迷人的抽象那就是將一個問題分解為子問題并且讓它們獨立運行，然后就是赤裸裸的現實。物理現實一次又一次地打了這種抽象的臉。 這只是問題的一部分。考慮一個制作蛋糕的工廠。我們不知何故在工人中分發了蛋糕制作任務，但是現在是時候讓工人把蛋糕放在盒子里了。那里有一個盒子，準備存放蛋糕。但是，在工人將蛋糕放入盒子之前，另一名工人投入并將蛋糕放入盒子中！我們的工人已經把蛋糕放進去了，然后就開始了！這兩個蛋糕被砸碎并毀了。這是常見的“共享內存”問題，產生我們稱之為競爭條件的問題，其結果取決于哪個工作人員可以首先將蛋糕放入盒子中（通常使用鎖機制來解決問題，因此一個工作人員可以先拿到盒子并防止蛋糕被砸爛）。 當“同時”執行的任務相互干擾時，會出現問題。它可以以如此微妙和偶然的方式發生，可能公平地說，并發性“可以說是確定性的，但實際上是非確定性的。”也就是說，你可以假設編寫通過維護和代碼檢查正常工作的并發程序。然而，在實踐中，我們編寫的并發程序似乎都能正常工作，但是在適當的條件下，將會失敗。這些情況可能永遠不會發生，或者在你在測試期間幾乎很難發現它們。實際上，編寫測試代碼通常無法為并發程序生成故障條件。由此產生的失敗只會偶爾發生，因此它們以客戶投訴的形式出現。 這是學習并發中最強有力的論點之一：如果你忽略它，你可能會受傷。 因此，并發似乎充滿了危險，如果這讓你有點害怕，這可能是一件好事。盡管Java 8在并發性方面做出了很大改進，但仍然沒有像編譯時驗證(compile-time verification)或受檢查的異常(checked exceptions)那樣的安全網來告訴你何時出現錯誤。通過并發，你只能依靠自己，只有知識淵博，保持懷疑和積極進取的人，才能用Java編寫可靠的并發代碼。