.NET Framework提供了一個(gè)非常好的開發(fā)環(huán)境，為開發(fā)人員帶來了非常大的好處。在這里就先來了解一下有關(guān).NET Framework ReaderWriterLock類的相關(guān)概念介紹。.NET Framework BCL 在 1.1 版本時(shí)，給我們提供了一個(gè).NET Framework ReaderWriterLock類來面對此種情景。但是很遺憾，Microsoft 官方不推薦使用該類。Jeffrey Richter 也在他的《CLR via C#》一書中對它進(jìn)行了嚴(yán)厲的批判。下面是該類不受歡迎的主要原因：#t#

性能

.NET Framework ReaderWriterLock類實(shí)在是太慢了。比如它的 AcquireReaderLock 方法比 Monitor 類的 Enter 方法要慢 5 倍左右，而等待爭奪寫鎖甚至比 Monitor 類慢 6 倍。

策略

假如某個(gè)線程完成寫入操作后，同時(shí)面臨讀線程和寫線程等待處理。ReaderWriterLock 會優(yōu)先釋放讀線程，而讓寫線程繼續(xù)等待。但我們使用讀寫鎖是因?yàn)榇嬖诖罅康淖x線程和非常少的寫線程，這樣寫線程很可能必須長時(shí)間地等待，造成寫線程饑餓，不能及時(shí)更新數(shù)據(jù)。更槽糕的情況是，假如寫線程一直等待，就會造成活鎖。反之，我們讓 ReaderWriterLock 采取寫線程優(yōu)先的策略。如果存在多個(gè)寫線程，而讀線程數(shù)量稀少，也會造成讀線程饑餓。幸運(yùn)的是，現(xiàn)實(shí)實(shí)踐中，這種情況很少出現(xiàn)。一旦發(fā)生這種情況，我們可以采取互斥鎖的辦法。

遞歸

.NET Framework ReaderWriterLock類支持鎖遞歸。這就意味著該鎖清楚的知道目前哪個(gè)線程擁有它。假如擁有該鎖的線程遞歸嘗試獲得該讀寫鎖，遞歸算法允許該線程獲得該讀寫鎖，并且增加獲得該鎖的計(jì)數(shù)。然而該線程必須釋放該鎖相同的次數(shù)以便線程不再擁有該鎖。盡管這看起來是個(gè)很好的特性，但是實(shí)現(xiàn)這個(gè)“特性”代價(jià)太高。首先，因?yàn)槎鄠€(gè)讀線程可以同時(shí)擁有該讀寫鎖，這必須讓該鎖為每個(gè)線程保持計(jì)數(shù)。

此外，還需要額外的內(nèi)存空間和時(shí)間來更新計(jì)數(shù)。這個(gè)特性對 ReaderWriterLock 類可憐的性能貢獻(xiàn)極大。其次，有些良好的設(shè)計(jì)需要一個(gè)線程在此處獲得該鎖，然后在別處釋放該鎖(比如 .NET 的異步編程架構(gòu))。因?yàn)檫@個(gè)遞歸特性，ReaderWriterLock 不支持這種編程架構(gòu)。

資源泄漏

在 .NET 2.0 之前的版本中， ReaderWriterLock 類會造成內(nèi)核對象泄露。這些對象只有在進(jìn)程終止后才能再次回收。幸運(yùn)的是，.NET 2.0 修正了這個(gè) Bug 。
此外，ReaderWriterLock 還有個(gè)令人擔(dān)心的危險(xiǎn)的非原子性操作。它就是 UpgradeToWriteLock 方法。這個(gè)方法實(shí)際上在更新到寫鎖前先釋放了讀鎖。這就讓其他線程有機(jī)會在此期間乘虛而入，從而獲得讀寫鎖且改變狀態(tài)。如果先更新到寫鎖，然后釋放讀鎖。假如兩個(gè)線程同時(shí)更新將會導(dǎo)致另外一個(gè)線程死鎖。

所以 Microsoft 決定構(gòu)建一個(gè)新類來一次性解決上述所有問題，這就是 ReaderWriterLockSlim 類。本來可以在原有的.NET Framework ReaderWriterLock類上修正錯(cuò)誤，但是考慮到兼容性和已存在的 API ，Microsoft 放棄了這種做法。當(dāng)然也可以標(biāo)記 ReaderWriterLock 類為 Obsolete，但是由于某些原因，這個(gè)類還有存在的必要。