知識星球分支或多執行緒程式設計是程式設計時最難最對的事情之一。這是由於它們的並行性質所致，即要求採用與使用單執行緒的線性程式設計完全不同的思維樣式。對於這個問題，恰當類比就是拋接雜耍表演者，必須在空中拋接多個球，而不要讓它們相互幹擾。這是一項重大挑戰。然而，透過正確的工具和思維樣式，這項挑戰是能應對的。
本文將深入介紹我為了簡化多執行緒程式設計和避免爭用條件、死鎖等其他問題而編寫的一些工具。可以說，工具鏈以語法糖和神奇委託為依據。不過，取用偉大的爵士音樂家 Miles Davis 的話：“在音樂中，沒有聲音比有聲音更重要。” 聲音間斷就產生了奇跡。
從另一個角度來說，不一定是關乎可以編碼什麼，而是關乎可以選擇不編碼什麼，因為你希望透過間斷程式碼行產生一點奇跡。取用 Bill Gates 的一句話：“根據程式碼行數來衡量工作質量就像透過重量來衡量飛機質量一樣。” 因此，我希望能幫助開發人員減少編碼量，而不是教導開發人員如何編寫更多程式碼。
同步挑戰
在多執行緒程式設計方面遇到的第一個問題是，同步對共享資源的訪問許可權。當兩個或多個執行緒共享對某個物件的訪問許可權且可能同時嘗試修改此物件時，就會出現這個問題。當 C# 首次釋出時，lock 陳述句實現了一種基本方法，可確保只有一個執行緒能訪問指定資源（如資料檔案），且效果很好。C# 中的 lock 關鍵字很容易理解，它獨自顛覆了我們對這個問題的思考方式。
不過，簡單的 lock 存在一個主要缺陷：它不區分只讀訪問許可權和寫入訪問許可權。例如，可能要從共享物件中讀取 10 個不同的執行緒，並且透過 System.Threading 名稱空間中的 ReaderWriterLockSlim 類授權這些執行緒同時訪問實體，而不導致問題發生。與 lock 陳述句不同，此類可便於指定程式碼是將內容寫入物件，還是隻從物件讀取內容。這樣一來，多個讀取器可以同時進入，但在其他所有讀寫執行緒均已完成自己的工作前，拒絕任何寫入程式碼訪問。
現在的問題是：如果使用 ReaderWriterLock 類，語法就會變得很麻煩，大量的重覆程式碼既降低了可讀性，又隨時間變化增加了維護複雜性，並且程式碼中通常會分散有多個 try 和 finally 塊。即使是簡單的拼寫錯誤，也可能會帶來日後有時極難發現的災難性影響。
透過將 ReaderWriterLockSlim 封裝到簡單的類中，這個問題瞬間解決，不僅重覆程式碼不再會出現，而且還降低了小拼寫錯誤毀一天勞動成果的風險。圖 1 中的類完全基於 lambda 技巧。可以說，這就是對一些委託應用的語法糖（假設存在幾個介面）。最重要的是，它在很大程度上有助於實現避免重覆程式碼原則 (DRY)。
圖 1：封裝 ReaderWriterLockSlim
1 public class Synchronizer where TImpl : TIWrite, TIRead {
2 ReaderWriterLockSlim _lock = new ReaderWriterLockSlim ();
3 TImpl _shared;
4
5 public Synchronizer (TImpl shared) {
6 _shared = shared;
7 }
8
9 public void Read (Action functor) {
10 _lock.EnterReadLock ();
11 try {
12 functor (_shared);
13 } finally {
14 _lock.ExitReadLock ();
15 }
16 }
17
18 public void Write (Action functor) {
19 _lock.EnterWriteLock ();
20 try {
21 functor (_shared);
22 } finally {
23 _lock.ExitWriteLock ();
24 }
25 }
26 }
圖 1 中只有 27 行程式碼，但卻精妙簡潔地確保物件跨多個執行緒進行同步。此類假定型別中有讀取介面和寫入介面。如果由於某種原因而無法更改需要將訪問許可權同步到的基礎類實現，也可以重覆模板類本身三次，透過這種方式使用它。基本用法如圖 2 所示。
圖 2：使用 Synchronizer 類
1 interface IReadFromShared {
2 string GetValue ();
3 }
4
5 interface IWriteToShared {
6 void SetValue (string value);
7 }
8
9 class MySharedClass : IReadFromShared, IWriteToShared {
10 string _foo;
11
12 public string GetValue () {
13 return _foo;
14 }
15
16 public void SetValue (string value) {
17 _foo = value;
18 }
19 }
20
21 void Foo (Synchronizer sync) {
22 sync.Write (x => {
23 x.SetValue ("new value");
24 });
25 sync.Read (x => {
26 Console.WriteLine (x.GetValue ());
27 })
28 }
在圖 2 的程式碼中，無論有多少執行緒在執行 Foo 方法，只要執行另一個 Read 或 Write 方法，就不會呼叫 Write 方法。不過，可以同時呼叫多個 Read 方法，而不必在程式碼中分散多個 try/catch/finally 陳述句，也不必不斷重覆相同的程式碼。我在此鄭重宣告，透過簡單字串來使用它是沒有意義的，因為 System.String 不可變。我使用簡單的字串物件來簡化示例。
基本思路是，必須將所有可以修改實體狀態的方法都新增到 IWriteToShared 介面中。同時，應將所有隻從實體讀取內容的方法都新增到 IReadFromShared 介面中。透過將諸如此類的問題分散到兩個不同的介面，並對基礎型別實現這兩個介面，可使用 Synchronizer 類來同步對實體的訪問許可權。這樣一來，將訪問許可權同步到程式碼的做法變得更簡單，並且基本上可以透過更具宣告性的方式這樣做。
在多執行緒程式設計方面，語法糖可能會決定成敗。除錯多執行緒程式碼通常極為困難，並且建立同步物件的單元測試可能會是徒勞無功之舉。
如果需要，可以建立只包含一個泛型引數的多載型別，不僅繼承自原始 Synchronizer 類，還將它的一個泛型引數作為型別引數三次傳遞到它的基類。這樣一來，就不需要讀取介面或寫入介面了，因為可以直接使用型別的具體實現。不過，這種方法要求手動處理需要使用 Write 或 Read 方法的部分。此外，雖然它的安全性稍差一點，但確實可便於將無法更改的類包裝到 Synchronizer 實體中。
用於分支的 lambda 集合
邁出第一步來使用神奇的 lambda（或在 C# 中稱為“委託”）後，不難想象，可以利用它們完成更多操作。例如，反覆出現的常見多執行緒主題是，讓多個執行緒與其他伺服器聯絡，以提取資料並將資料傳回給呼叫方。
最簡單的例子就是，應用程式從 20 個網頁讀取資料，併在完成後將 HTML 傳回給一個根據所有網頁的內容建立某種聚合結果的執行緒。除非為每個檢索方法都建立一個執行緒，否則此程式碼的執行速度比預期慢得多：99% 的所有執行時間可能會花在等待 HTTP 請求傳回上。
在一個執行緒上執行此程式碼的效率很低，並且執行緒建立語法非常容易出錯。隨著你支援多個執行緒及其助理物件，挑戰變得更嚴峻，開發人員不得不在編寫程式碼時使用重覆程式碼。意識到可以建立委託集合和用於包裝這些委託的類後，便能使用一個方法呼叫來建立所有執行緒。這樣一來，建立執行緒就輕鬆多了。
圖 3 中的一段程式碼建立兩個並行執行的此類 lambda。請註意，此程式碼實際上來自我的第一版 Lizzie 指令碼語言的單元測試 (bit.ly/2FfH5y8)。
圖 3：建立 lambda
1 public void ExecuteParallel_1 () {
2 var sync = new Synchronizer<string, string, string> ("initial_");
3
4 var actions = new Actions ();
5 actions.Add (() => sync.Assign ((res) => res + "foo"));
6 actions.Add (() => sync.Assign ((res) => res + "bar"));
7
8 actions.ExecuteParallel ();
9
10 string result = null;
11 sync.Read (delegate (string val) { result = val; });
12 Assert.AreEqual (true, "initial_foobar" == result || result == "initial_barfoo");
13 }
仔細看看這段程式碼便會發現，計算結果並未假定我的兩個 lambda 的執行存先後順序。執行順序並未明確指定，並且這些 lambda 是在不同的執行緒上執行。這是因為，使用圖 3 中的 Actions 類，可以向它新增委託，這樣稍後就能決定是要並行執行委託，還是按順序執行委託。
為此，必須使用首選機制建立並執行許多 lambda。在圖 3 中可以看到前面提到的 Synchronizer 類，用於同步對共享字串資源的訪問許可權。不過，它對 Synchronizer 使用了新方法 Assign，我並未在圖 1中的串列內為 Synchronizer 類新增此方法。Assign 方法使用前面 Write 和 Read 方法中使用的相同“lambda 技巧”。
若要研究 Actions 類的實現，請務必下載 Lizzie 版本 0.1，因為我在後面推出的版本中完全重寫了程式碼，使之成為獨立程式語言。
C# 中的函式式程式設計
大多數開發人員往往認為，C# 幾乎與面向物件的程式設計 (OOP) 同義或至少密切相關，事實顯然如此。不過，透過重新思考如何使用 C#，並深入瞭解它的各方面功能，解決一些問題就變得更加簡單了。目前形式的 OOP 不太易於重用，原因很多是因為它是強型別。
例如，如果重用一個類，就不得不重用初始類取用的每個類（在兩種情況下，類都是透過組合和繼承進行使用）。此外，類重用還會強制重用這些第三方類取用的所有類等。如果這些類是在不同的程式集中實現，必須新增各種各樣的程式集，才能獲得對一個型別上單個方法的訪問許可權。
我曾經看過一個可以說明這個問題的類比：“雖然想要的是香蕉，但最終得到的是手拿香蕉的大猩猩，以及大猩猩所居住的熱帶雨林。” 將這種情況與使用更動態的語言（如 JavaScript）進行重用做比較，後者並不關心型別，只要它實現函式本身使用的函式即可。透過略微寬鬆型別方法生成的程式碼更靈活、更易於重用。委託可以實現這一點。
可使用 C# 來改善跨多個專案重用程式碼的過程。只需要理解函式或委託也可以是物件，並且可以透過弱型別方式控制這些物件的集合。
早在 2018 年 11 月發行的《MSDN 雜誌》中，我發表過一篇標題為“使用符號委託建立你自己的指令碼語言”的文章 (msdn.com/magazine/mt830373)。本文中提到的有關委託的思路是在這篇文章的基礎之上形成。本文還介紹了 Lizzie，這是我的自製指令碼語言，它的存在歸功於這種以委託為中心的思維樣式。如果我使用 OOP 規則建立了 Lizzie，我會認為，它在大小上可能至少大一個數量級。
當然，如今 OOP 和強型別處於主導地位，想要找到一個主要必需技能不要求它的職位描述，幾乎是不可能的。我在此鄭重宣告，我建立 OOP 程式碼的時間已超過 25 年，所以，我與任何人一樣都會因為對強型別有偏見而感到內疚。然而，如今我在編碼方法上更加務實，對類層次結構的最終外觀失去興趣。
並不是我不欣賞外觀精美的類層次結構，而是收益遞減。新增到層次結構中的類越多，它就變得越臃腫，直到因不堪重壓而崩潰。有時，卓越的設計只用很少的方法、更少的類和大多數鬆散耦合的函式，這樣就可以輕鬆擴充套件程式碼，也就不需要“引入大猩猩和熱帶雨林”了。
回到本文反覆出現的主題（從 Miles Davis 的音樂方法中獲得靈感）：少即是多（“沒有聲音比有聲音更重要”）。 程式碼也不例外。間斷程式碼行往往會產生奇跡，最佳解決方案的衡量依據更多是不編碼什麼，而不是編碼什麼。連傻瓜也可以將喇叭吹響，但只有為數不多的人才能用喇叭吹奏出音樂。像 Miles 這樣能創造出奇跡的人就更少了。
原文作者：Thomas Hansen
原文地址：Minimize Complexity in Multithreaded C# Code
