Is the ConcurrentDictionary thread-safe to the point that I can use it for a static cache?
问题：
Basically, if I want to do the following:
public class SomeClass
{
private static ConcurrentDictionary<..., ...> Cache { get; set; }
}Does this let me avoid using locks all over the place?
解答：
Yes, it is thread safe and yes it avoids you using locks all over the place (whatever that means). Of course that will only provide you a thread safe access to the data stored in this dictionary, but if the data itself is not thread safe then you need to synchronize access to it of course. Imagine for example that you have stored in this cache a List<T>. Now thread1 fetches this list (in a thread safe manner as the concurrent dictionary guarantees you this) and then starts enumerating over this list. At exactly the same time thread2 fetches this very same list from the cache (in a thread safe manner as the concurrent dictionary guarantees you this) and writes to the list (for example it adds a value). Conclusion: if you haven't synchronized thread1 it will get into trouble.
As far as using it as a cache is concerned, well, that's probably not a good idea. For caching I would recommend you what is already built into the framework. Classes such as MemoryCache for example. The reason for this is that what is built into the System.Runtime.Caching assembly is, well, explicitly built for caching => it handles things like automatic expiration of data if you start running low on memory, callbacks for cache expiration items, and you would even be able to distribute your cache over multiple servers using things like memcached, AppFabric, ..., all things that you would can't dream of with a concurrent dictionary.
Is the MemoryCache class thread-safe like the ConcurrentDictionary is though? – michael
@michael, yes it is thread safe but absolutely the same remark stands true about synchronizing access to non thread-safe objects that you might be storing into this cache. – Darin Dimitrov
Oh, I understand that part. But, just so that other readers can understand I'm going to reiterate it. You're saying that both the ConcurrentDictionary and MemoryCache class are thread-safe, but the contents within are not guaranteed to be thread-safe. :) – michael
@michael, exactly, nicely put. My English is so poor that I can't express myself. – Darin Dimitrov
ConcurrentDictionary
internal class Program
{
private static void Main()
{
try
{
var dictionary = new ConcurrentDictionary<string, int>();
for (char c = 'A'; c <= 'F'; c++)
{
dictionary.TryAdd(c.ToString(), c - 'A' + );
} var iterationTask = new Task(() =>
{
foreach (var pair in dictionary)
{
Console.WriteLine(pair.Key + ":" + pair.Value);
}
}); var updateTask = new Task(() =>
{
foreach (var pair in dictionary)
{
dictionary[pair.Key] = pair.Value + ;
}
}); var addTask = new Task(() =>
{
for (char c = 'G'; c <= 'K'; c++)
{
//dictionary[c.ToString()] = c - 'A' + 1;
bool flag = dictionary.TryAdd(c.ToString(), c - 'A' + );
if (!flag)
{
Console.WriteLine("添加{0}失败", c);
}
else
{
Console.WriteLine("添加{0}成功", c);
}
}
}); var deleteTask=new Task(() =>
{
foreach (var pair in dictionary)
{
if (Convert.ToChar(pair.Key) <= 'F')
{
int number;
bool flag = dictionary.TryRemove(pair.Key, out number);
if (!flag)
{
Console.WriteLine("移除{0}失败", pair.Key);
}
else
{
Console.WriteLine("移除{0}成功", pair.Key);
}
}
}
}); updateTask.Start();
iterationTask.Start();
addTask.Start();
deleteTask.Start();
Task.WaitAll(updateTask, iterationTask,addTask,deleteTask); }
catch (Exception ex)
{
while (ex != null)
{
Console.WriteLine(ex.Message);
ex = ex.InnerException;
}
}
Console.ReadLine();
}
}
执行结果几乎每次都不相同，但是总能成功执行。
Dictionary
非线程安全的，代码执行的时候，会提示，集合已修改
internal class Program
{
private static void Main()
{
try
{
var dictionary = new Dictionary<string, int>();
for (char c = 'A'; c <= 'F'; c++)
{
dictionary.Add(c.ToString(), c - 'A' + );
} var iterationTask = new Task(() =>
{
foreach (var pair in dictionary)
{
Console.WriteLine(pair.Key + ":" + pair.Value);
}
}); var updateTask = new Task(() =>
{
foreach (var pair in dictionary)
{
dictionary[pair.Key] = pair.Value + ;
}
}); var addTask = new Task(() =>
{
for (char c = 'G'; c <= 'K'; c++)
{
dictionary.Add(c.ToString(), c - 'A' + );
}
}); var deleteTask = new Task(() =>
{
foreach (var pair in dictionary)
{
if (Convert.ToChar(pair.Key) <= 'F')
{
bool flag = dictionary.Remove(pair.Key);
if (!flag)
{
Console.WriteLine("移除{0}失败", pair.Key);
}
else
{
Console.WriteLine("移除{0}成功", pair.Key);
}
}
}
}); updateTask.Start();
iterationTask.Start();
addTask.Start();
deleteTask.Start();
Task.WaitAll(updateTask, iterationTask, addTask, deleteTask); }
catch (Exception ex)
{
while (ex != null)
{
Console.WriteLine(ex.Message);
ex = ex.InnerException;
}
}
Console.ReadLine();
}
}
线程不安全的方法
http://www.cnblogs.com/chucklu/p/4468057.html
https://*.com/questions/51138333/is-this-concurrentdictionary-thread-safe
No; the dictionary could change between ContainsKey() & TryAdd().
You should never call two methods in a row on ConcurrentDictionary, unless you're sure you don't care if it changes between them.
Similarly, you can't loop through the dictionary, since it might change during the loop.
Instead, you should use its more-complex methods (like TryAdd(), which will check and add in a single atomic operation.
Also, as you suggested, the entire dictionary might be replaced.
https://*.com/questions/38323009/which-members-of-nets-concurrentdictionary-are-thread-safe
There is a specific section in the documentation that makes clear not everything is thread-safe in the ConcurrentDictionary<TKey, TValue>:
All these operations are atomic and are thread-safe with regards to all other operations on the
ConcurrentDictionary<TKey, TValue>class. The only exceptions are the methods that accept a delegate, that is,AddOrUpdateandGetOrAdd. For modifications and write operations to the dictionary,ConcurrentDictionary<TKey, TValue>uses fine-grained locking to ensure thread safety. (Read operations on the dictionary are performed in a lock-free manner.) However, delegates for these methods are called outside the locks to avoid the problems that can arise from executing unknown code under a lock. Therefore, the code executed by these delegates is not subject to the atomicity of the operation.
So there are some general exclusions and some situations specific to ConcurrentDictionary<TKey, TValue>:
- The delegates on
AddOrUpdateandGetOrAddare not called in a thread-safe matter. - Methods or properties called on an explicit interface implementation are not guaranteed to be thread-safe;
- Extension methods called on the class are not guaranteed to be thread-safe;
- All other operations on public members of the class are thread-safe.
最后是用MemoryCache来处理?
https://*.com/questions/21269170/locking-pattern-for-proper-use-of-net-memorycache
This is my 2nd iteration of the code. Because MemoryCache is thread safe you don't need to lock on the initial read, you can just read and if the cache returns null then do the lock check to see if you need to create the string. It greatly simplifies the code.
const string CacheKey = "CacheKey";
static readonly object cacheLock = new object();
private static string GetCachedData()
{ //Returns null if the string does not exist, prevents a race condition where the cache invalidates between the contains check and the retreival.
var cachedString = MemoryCache.Default.Get(CacheKey, null) as string; if (cachedString != null)
{
return cachedString;
} lock (cacheLock)
{
//Check to see if anyone wrote to the cache while we where waiting our turn to write the new value.
cachedString = MemoryCache.Default.Get(CacheKey, null) as string; if (cachedString != null)
{
return cachedString;
} //The value still did not exist so we now write it in to the cache.
var expensiveString = SomeHeavyAndExpensiveCalculation();
CacheItemPolicy cip = new CacheItemPolicy()
{
AbsoluteExpiration = new DateTimeOffset(DateTime.Now.AddMinutes())
};
MemoryCache.Default.Set(CacheKey, expensiveString, cip);
return expensiveString;
}
}
EDIT: The below code is unnecessary but I wanted to leave it to show the original method. It may be useful to future visitors who are using a different collection that has thread safe reads but non-thread safe writes (almost all of classes under the System.Collections namespace is like that).
Here is how I would do it using ReaderWriterLockSlim to protect access. You need to do a kind of "Double Checked Locking" to see if anyone else created the cached item while we where waiting to to take the lock.
const string CacheKey = "CacheKey";
static readonly ReaderWriterLockSlim cacheLock = new ReaderWriterLockSlim();
static string GetCachedData()
{
//First we do a read lock to see if it already exists, this allows multiple readers at the same time.
cacheLock.EnterReadLock();
try
{
//Returns null if the string does not exist, prevents a race condition where the cache invalidates between the contains check and the retreival.
var cachedString = MemoryCache.Default.Get(CacheKey, null) as string; if (cachedString != null)
{
return cachedString;
}
}
finally
{
cacheLock.ExitReadLock();
} //Only one UpgradeableReadLock can exist at one time, but it can co-exist with many ReadLocks
cacheLock.EnterUpgradeableReadLock();
try
{
//We need to check again to see if the string was created while we where waiting to enter the EnterUpgradeableReadLock
var cachedString = MemoryCache.Default.Get(CacheKey, null) as string; if (cachedString != null)
{
return cachedString;
} //The entry still does not exist so we need to create it and enter the write lock
var expensiveString = SomeHeavyAndExpensiveCalculation();
cacheLock.EnterWriteLock(); //This will block till all the Readers flush.
try
{
CacheItemPolicy cip = new CacheItemPolicy()
{
AbsoluteExpiration = new DateTimeOffset(DateTime.Now.AddMinutes())
};
MemoryCache.Default.Set(CacheKey, expensiveString, cip);
return expensiveString;
}
finally
{
cacheLock.ExitWriteLock();
}
}
finally
{
cacheLock.ExitUpgradeableReadLock();
}
}