帶鎖或Conconncy字典的詞典？

這是優選的在多線程應用程序： Dictionary與鎖定對象或 Concurrency Dictionary 帶鎖或Conconncy字典的詞典？

哪些是有效的，爲什麼我應該使用一種或另一種？

編輯1：存儲GUID作爲關鍵和布爾值作爲。

編輯2：2個以上的工作線程，一個UI線程。

2012-03-26 radu florescu

這將取決於情況。 – 2012-03-26 07:44:44

[dictionary-locking-vs-concurrentdictionary]可能重複（http://stackoverflow.com/questions/1949131/net-dictionary-locking-vs-concurrentdictionary） – 2013-05-03 18:46:15

仔細約ConcurrentDictionary閱讀。它有一些不明顯的特徵。

下面是其中一些：

如果兩個線程調用AddOrUpdate沒有保證哪個廠家代表將被調用，甚至不能保證，如果一個工廠的代表，會產生一些項目，這個項目將是存儲在字典中。
由GetEnumerator調用獲得的枚舉器是而不是快照，並可能在枚舉過程中被修改（這不會導致任何異常）。
Keys和Values屬性是對應集合的快照，並可能不對應於實際字典狀態。
等

所以請有關ConcurrentDictionary再次讀取，並決定是否這種行爲是你所需要的。

希望這會有所幫助！

來源

2012-03-26 13:07:15 levanovd

當你實現一個鎖對象字典，你主要關注的似乎是線程安全的。所以看起來，併發詞典已經處理了這個問題。我認爲重新發明車輪沒有意義。

來源

2012-03-26 07:34:50 daryal

並不總是如此。如果速度很快，手動鎖定可能會更好。 – 2012-03-26 07:46:01

根據情況，您可能是對的，另一方面，這種情況下沒有適用的績效數據。定製測試可以驗證性能增益（如果有的話）。 – daryal 2012-03-26 07:50:18

速度確實很重要。 – 2012-03-26 07:53:39

我認爲兩者都將提供線程安全的，但使用字典與鎖定對象將限制可以在使用併發字典併發訪問字典爲1線程的數量，你可以指定併發級別（即線程數量可以同時訪問字典）。如果性能確實重要，我相信Concurrent Dictionary應該是您的選擇。

來源

2012-03-26 12:58:53

我會說你有以下選項。

一些新的框架4.0類：

ConcurrentDictionary。工作快速可靠。
ConcurrentBag。這是無序集合對象，因此它可以更快，但西裝，如果你不只需要排序。
ConcurrentStack。它是傳統的後進先出（Last-In First Out）數據結構的實現，它提供了無需外部同步的線程安全訪問。
ConcurrentQueue。這是一個線程安全的FIFO（先入先出）收集。

所有新的4.0類工作得更快，但必須由levanovd提到的一些功能。這些類的性能比較，你可以找到here。

從早期版本的一些經典解決方案：

字典。簡單包裝到鎖
字典 + ReaderWriterLock。比前一個更好，因爲有讀寫鎖。所以有幾個線程可以讀取，只有一個 - 寫入。
字典 + ReaderWriterLockSlim。這只是前一個的優化。
Hashtable。從我的經驗來看，這是最慢的方法。檢查Hashtable.Synchronized()方法，這是一個隨時可以從微軟解決方案。

如果我不得不使用框架v3.5版本的限制，我會用字典 + ReaderWriterLock或ReaderWriterLockSlim。

來源

2012-10-28 22:58:37

帶鎖或Conconncy字典的詞典？

回答

相關問題