<!-- 不知道是否可以找到之前翻譯的針對速度感覺太直了 --> ## 并發為速度而生 在聽說并發編程的問題之后，你可能會想知道它是否值得這么麻煩。答案是“不，除非你的程序運行速度不夠快。”并且在決定用它之前你會想要仔細思考。不要隨便跳進并發編程的悲痛之中。如果有一種方法可以在更快的機器上運行你的程序，或者如果你可以對其進行分析并發現瓶頸并在該位置替換更快的算法，那么請執行此操作。只有在顯然沒有其他選擇時才開始使用并發，然后僅在必要的地方去使用它。 速度問題一開始聽起來很簡單：如果你想要一個程序運行得更快，將其分解成碎片并在一個單獨的處理器上運行每個部分。由于我們能夠提高時鐘速度流（至少對于傳統芯片），速度的提高是出現在多核處理器的形式而不是更快的芯片。為了使你的程序運行得更快，你必須學會如何利用那些額外的處理器，這是并發性給你的一個建議。 使用多處理器機器，可以在這些處理器之間分配多個任務，這可以顯著提高吞吐量。強大的多處理器Web服務器通常就是這種情況，它可以在程序中為CPU分配大量用戶請求，每個請求分配一個線程。 但是，并發性通常可以提高在單個處理器上運行的程序的性能。這聽起來有點違反直覺。如果考慮一下，由于上下文切換的成本增加（從一個任務更改為另一個任務），在單個處理器上運行的并發程序實際上應該比程序的所有部分順序運行具有更多的開銷。在表面上，將程序的所有部分作為單個任務運行并節省上下文切換的成本似乎更便宜。 可以產生影響的問題是阻塞。如果你的程序中的一個任務由于程序控制之外的某些條件（通常是I/O）而無法繼續，我們會說任務或線程阻塞（在我們的科幻故事中，克隆體已敲門而且是等待它打開）。如果沒有并發性，整個程序就會停止，直到外部條件發生變化。但是，如果使用并發編寫程序，則當一個任務被阻止時，程序中的其他任務可以繼續執行，因此程序繼續向前移動。實際上，從性能的角度來看，在單處理器機器上使用并發是沒有意義的，除非其中一個任務可能阻塞。 單處理器系統中性能改進的一個常見例子是事件驅動編程，特別是用戶界面編程。考慮一個程序執行一些長時間運行操作，從而最終忽略用戶輸入和無響應。如果你有一個“退出”按鈕，你不想在你編寫的每段代碼中輪詢它。這會產生笨拙的代碼，無法保證程序員不會忘記執行檢查。沒有并發性，生成響應式用戶界面的唯一方法是讓所有任務定期檢查用戶輸入。通過創建單獨的執行線程來響應用戶輸入，該程序保證了一定程度的響應。 實現并發的直接方法是在操作系統級別，使用與線程不同的進程。進程是一個在自己的地址空間內運行的自包含程序。進程很有吸引力，因為操作系統通常將一個進程與另一個進程隔離，因此它們不會相互干擾，這使得進程編程相對容易。相比之下，線程共享內存和I/O等資源，因此編寫多線程程序時遇到的困難是在不同的線程驅動的任務之間協調這些資源，一次不能通過多個任務訪問它們。 <!-- 文獻引用未加，因為暫時沒看到很好的解決辦法 --> 有些人甚至提倡將進程作為并發的唯一合理方法[^1]，但不幸的是，通常存在數量和開銷限制，從而阻止了在并發范圍內的適用性（最終你會習慣標準的并發限制，“這種方法適用于一些情況但不適用于其他情況”） 一些編程語言旨在將并發任務彼此隔離。這些通常被稱為_函數式語言_，其中每個函數調用不產生其他影響（因此不能與其他函數干涉），因此可以作為獨立的任務來驅動。Erlang就是這樣一種語言，它包括一個任務與另一個任務進行通信的安全機制。如果你發現程序的某一部分必須大量使用并發性并且你在嘗試構建該部分時遇到了過多的問題，那么你可能會考慮使用專用并發語言創建程序的那一部分。 <!-- 文獻標記 --> Java采用了更傳統的方法[^2]，即在順序語言之上添加對線程的支持而不是在多任務操作系統中分配外部進程，線程在執行程序所代表的單個進程中創建任務交換。 并發性會帶來成本，包括復雜性成本，但可以通過程序設計，資源平衡和用戶便利性的改進來抵消。通常，并發性使你能夠創建更加松散耦合的設計；除此以外，你必須特別關注那些使用了并發操作的代碼。