怎么最大限度地降低多線程C#代碼復雜性的示例分析

小編給大家分享一下怎么最大限度地降低多線程C#代碼復雜性的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

分支或多線程編程是編程時最難最對的事情之一。這是由于它們的并行性質(zhì)所致，即要求采用與使用單線程的線性編程完全不同的思維模式。對于這個問題，恰當類比就是拋接雜耍表演者，必須在空中拋接多個球，而不要讓它們相互干擾。這是一項重大挑戰(zhàn)。然而，通過正確的工具和思維模式，這項挑戰(zhàn)是能應對的。

本文將深入介紹我為了簡化多線程編程和避免爭用條件、死鎖等其他問題而編寫的一些工具?？梢哉f，工具鏈以語法糖和神奇委托為依據(jù)。不過，引用偉大的爵士音樂家 Miles Davis 的話：“在音樂中，沒有聲音比有聲音更重要?！?聲音間斷就產(chǎn)生了奇跡。

從另一個角度來說，不一定是關乎可以編碼什么，而是關乎可以選擇不編碼什么，因為你希望通過間斷代碼行產(chǎn)生一點奇跡。引用 Bill Gates 的一句話：“根據(jù)代碼行數(shù)來衡量工作質(zhì)量就像通過重量來衡量飛機質(zhì)量一樣?！?因此，我希望能幫助開發(fā)人員減少編碼量，而不是教導開發(fā)人員如何編寫更多代碼。

同步挑戰(zhàn)

在多線程編程方面遇到的第一個問題是，同步對共享資源的訪問權限。當兩個或多個線程共享對某個對象的訪問權限且可能同時嘗試修改此對象時，就會出現(xiàn)這個問題。當 C# 首次發(fā)布時，lock 語句實現(xiàn)了一種基本方法，可確保只有一個線程能訪問指定資源（如數(shù)據(jù)文件），且效果很好。C# 中的 lock 關鍵字很容易理解，它獨自顛覆了我們對這個問題的思考方式。

不過，簡單的 lock 存在一個主要缺陷：它不區(qū)分只讀訪問權限和寫入訪問權限。例如，可能要從共享對象中讀取 10 個不同的線程，并且通過 System.Threading 命名空間中的 ReaderWriterLockSlim 類授權這些線程同時訪問實例，而不導致問題發(fā)生。與 lock 語句不同，此類可便于指定代碼是將內(nèi)容寫入對象，還是只從對象讀取內(nèi)容。這樣一來，多個讀取器可以同時進入，但在其他所有讀寫線程均已完成自己的工作前，拒絕任何寫入代碼訪問。

現(xiàn)在的問題是：如果使用 ReaderWriterLock 類，語法就會變得很麻煩，大量的重復代碼既降低了可讀性，又隨時間變化增加了維護復雜性，并且代碼中通常會分散有多個 try 和 finally 塊。即使是簡單的拼寫錯誤，也可能會帶來日后有時極難發(fā)現(xiàn)的災難性影響。

通過將 ReaderWriterLockSlim 封裝到簡單的類中，這個問題瞬間解決，不僅重復代碼不再會出現(xiàn)，而且還降低了小拼寫錯誤毀一天勞動成果的風險。圖 1 中的類完全基于 lambda 技巧?？梢哉f，這就是對一些委托應用的語法糖（假設存在幾個接口）。最重要的是，它在很大程度上有助于實現(xiàn)避免重復代碼原則 (DRY)。

1：封裝 ReaderWriterLockSlim

public class Synchronizer<TImpl, TIRead, TIWrite> where TImpl : TIWrite, TIRead {
  ReaderWriterLockSlim _lock = new ReaderWriterLockSlim ();
  TImpl _shared;

  public Synchronizer (TImpl shared) {
    _shared = shared;
  }

  public void Read (Action<TIRead> functor) {
    _lock.EnterReadLock ();
    try {
      functor (_shared);
    } finally {
      _lock.ExitReadLock ();
    }
  }

  public void Write (Action<TIWrite> functor) {
    _lock.EnterWriteLock ();
    try {
      functor (_shared);
    } finally {
      _lock.ExitWriteLock ();
    }
  }
}

1 中只有 27 行代碼，但卻精妙簡潔地確保對象跨多個線程進行同步。此類假定類型中有讀取接口和寫入接口。如果由于某種原因而無法更改需要將訪問權限同步到的基礎類實現(xiàn)，也可以重復模板類本身三次，通過這種方式使用它?；居梅ㄈ?2 所示。

2：使用 Synchronizer 類

interface IReadFromShared {
  string GetValue ();
}

interface IWriteToShared {
  void SetValue (string value);
}

class MySharedClass : IReadFromShared, IWriteToShared {
  string _foo;

  public string GetValue () {
    return _foo;
  }

  public void SetValue (string value) {
    _foo = value;
  }
}

void Foo (Synchronizer<MySharedClass, IReadFromShared, IWriteToShared> sync) {
  sync.Write (x => {
    x.SetValue ("new value");
  });
  sync.Read (x => {
    Console.WriteLine (x.GetValue ());
  })
}

在 2 的代碼中，無論有多少線程在執(zhí)行 Foo 方法，只要執(zhí)行另一個 Read 或 Write 方法，就不會調(diào)用 Write 方法。不過，可以同時調(diào)用多個 Read 方法，而不必在代碼中分散多個 try/catch/finally 語句，也不必不斷重復相同的代碼。我在此鄭重聲明，通過簡單字符串來使用它是沒有意義的，因為 System.String 不可變。我使用簡單的字符串對象來簡化示例。

基本思路是，必須將所有可以修改實例狀態(tài)的方法都添加到 IWriteToShared 接口中。同時，應將所有只從實例讀取內(nèi)容的方法都添加到 IReadFromShared 接口中。通過將諸如此類的問題分散到兩個不同的接口，并對基礎類型實現(xiàn)這兩個接口，可使用 Synchronizer 類來同步對實例的訪問權限。這樣一來，將訪問權限同步到代碼的做法變得更簡單，并且基本上可以通過更具聲明性的方式這樣做。

在多線程編程方面，語法糖可能會決定成敗。調(diào)試多線程代碼通常極為困難，并且創(chuàng)建同步對象的單元測試可能會是徒勞無功之舉。

如果需要，可以創(chuàng)建只包含一個泛型參數(shù)的重載類型，不僅繼承自原始 Synchronizer 類，還將它的一個泛型參數(shù)作為類型參數(shù)三次傳遞到它的基類。這樣一來，就不需要讀取接口或?qū)懭虢涌诹?，因為可以直接使用類型的具體實現(xiàn)。不過，這種方法要求手動處理需要使用 Write 或 Read 方法的部分。此外，雖然它的安全性稍差一點，但確實可便于將無法更改的類包裝到 Synchronizer 實例中。

用于分支的 lambda 集合

邁出第一步來使用神奇的 lambda（或在 C# 中稱為“委托”）后，不難想象，可以利用它們完成更多操作。例如，反復出現(xiàn)的常見多線程主題是，讓多個線程與其他服務器聯(lián)系，以提取數(shù)據(jù)并將數(shù)據(jù)返回給調(diào)用方。

最簡單的例子就是，應用程序從 20 個網(wǎng)頁讀取數(shù)據(jù)，并在完成后將 HTML 返回給一個根據(jù)所有網(wǎng)頁的內(nèi)容創(chuàng)建某種聚合結果的線程。除非為每個檢索方法都創(chuàng)建一個線程，否則此代碼的運行速度比預期慢得多：99% 的所有執(zhí)行時間可能會花在等待 HTTP 請求返回上。

在一個線程上運行此代碼的效率很低，并且線程創(chuàng)建語法非常容易出錯。隨著你支持多個線程及其助理對象，挑戰(zhàn)變得更嚴峻，開發(fā)人員不得不在編寫代碼時使用重復代碼。意識到可以創(chuàng)建委托集合和用于包裝這些委托的類后，便能使用一個方法調(diào)用來創(chuàng)建所有線程。這樣一來，創(chuàng)建線程就輕松多了。

3 中的一段代碼創(chuàng)建兩個并行運行的此類 lambda。請注意，此代碼實際上來自我的第一版 Lizzie 腳本語言的單元測試 (bit.ly/2FfH5y8)。

3：創(chuàng)建 lambda

public void ExecuteParallel_1 () {
  var sync = new Synchronizer<string, string, string> ("initial_");

  var actions = new Actions ();
  actions.Add (() => sync.Assign ((res) => res + "foo"));
  actions.Add (() => sync.Assign ((res) => res + "bar"));

  actions.ExecuteParallel ();

  string result = null;
  sync.Read (delegate (string val) { result = val; });
  Assert.AreEqual (true, "initial_foobar" == result || result == "initial_barfoo");
}

仔細看看這段代碼便會發(fā)現(xiàn)，計算結果并未假定我的兩個 lambda 的執(zhí)行存先后順序。執(zhí)行順序并未明確指定，并且這些 lambda 是在不同的線程上執(zhí)行。這是因為，使用圖 3 中的 Actions 類，可以向它添加委托，這樣稍后就能決定是要并行執(zhí)行委托，還是按順序執(zhí)行委托。

為此，必須使用首選機制創(chuàng)建并執(zhí)行許多 lambda。在圖 3 中可以看到前面提到的 Synchronizer 類，用于同步對共享字符串資源的訪問權限。不過，它對 Synchronizer 使用了新方法 Assign，我并未在圖 1中的列表內(nèi)為 Synchronizer 類添加此方法。Assign 方法使用前面 Write 和 Read 方法中使用的相同“l(fā)ambda 技巧”。

若要研究 Actions 類的實現(xiàn)，請務必下載 Lizzie 版本 0.1，因為我在后面推出的版本中完全重寫了代碼，使之成為獨立編程語言。

C# 中的函數(shù)式編程

大多數(shù)開發(fā)人員往往認為，C# 幾乎與面向?qū)ο蟮木幊?(OOP) 同義或至少密切相關，事實顯然如此。不過，通過重新思考如何使用 C#，并深入了解它的各方面功能，解決一些問題就變得更加簡單了。目前形式的 OOP 不太易于重用，原因很多是因為它是強類型。

例如，如果重用一個類，就不得不重用初始類引用的每個類（在兩種情況下，類都是通過組合和繼承進行使用）。此外，類重用還會強制重用這些第三方類引用的所有類等。如果這些類是在不同的程序集中實現(xiàn)，必須添加各種各樣的程序集，才能獲得對一個類型上單個方法的訪問權限。

我曾經(jīng)看過一個可以說明這個問題的類比：“雖然想要的是香蕉，但最終得到的是手拿香蕉的大猩猩，以及大猩猩所居住的熱帶雨林?！?將這種情況與使用更動態(tài)的語言（如 JavaScript）進行重用做比較，后者并不關心類型，只要它實現(xiàn)函數(shù)本身使用的函數(shù)即可。通過略微寬松類型方法生成的代碼更靈活、更易于重用。委托可以實現(xiàn)這一點。

可使用 C# 來改善跨多個項目重用代碼的過程。只需要理解函數(shù)或委托也可以是對象，并且可以通過弱類型方式控制這些對象的集合。

早在 2018 年 11 月發(fā)行的《MSDN 雜志》中，我發(fā)表過一篇標題為“使用符號委托創(chuàng)建你自己的腳本語言”的文章 (msdn.com/magazine/mt830373)。本文中提到的有關委托的思路是在這篇文章的基礎之上形成。本文還介紹了 Lizzie，這是我的自制腳本語言，它的存在歸功于這種以委托為中心的思維模式。如果我使用 OOP 規(guī)則創(chuàng)建了 Lizzie，我會認為，它在大小上可能至少大一個數(shù)量級。

當然，如今 OOP 和強類型處于主導地位，想要找到一個主要必需技能不要求它的職位描述，幾乎是不可能的。我在此鄭重聲明，我創(chuàng)建 OOP 代碼的時間已超過 25 年，所以，我與任何人一樣都會因為對強類型有偏見而感到內(nèi)疚。然而，如今我在編碼方法上更加務實，對類層次結構的最終外觀失去興趣。

并不是我不欣賞外觀精美的類層次結構，而是收益遞減。添加到層次結構中的類越多，它就變得越臃腫，直到因不堪重壓而崩潰。有時，卓越的設計只用很少的方法、更少的類和大多數(shù)松散耦合的函數(shù)，這樣就可以輕松擴展代碼，也就不需要“引入大猩猩和熱帶雨林”了。

回到本文反復出現(xiàn)的主題（從 Miles Davis 的音樂方法中獲得靈感）：少即是多（“沒有聲音比有聲音更重要”）。 代碼也不例外。間斷代碼行往往會產(chǎn)生奇跡，最佳解決方案的衡量依據(jù)更多是不編碼什么，而不是編碼什么。連傻瓜也可以將喇叭吹響，但只有為數(shù)不多的人才能用喇叭吹奏出音樂。像 Miles 這樣能創(chuàng)造出奇跡的人就更少了。

以上是“怎么最大限度地降低多線程C#代碼復雜性的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道！