我有下面的课。
class Test{
public HashSet<string> Data = new HashSet<string>();
}
我需要从不同的线程改变字段“数据”，所以我想对我目前的线程安全实现的一些意见。
class Test{
public HashSet<string> Data = new HashSet<string>();
public void Add(string Val){
lock(Data) Data.Add(Val);
}
public void Remove(string Val){
lock(Data) Data.Remove(Val);
}
}
是否有更好的解决方案，直接到字段并保护它免受多线程的并发访问?
当前回答
我发现既不能简单地锁定System.Collections.Generic的添加和删除方法。HashSet，或者包装框架的ConcurrentDictionary在需要良好性能的“高吞吐量”场景中是足够的。
通过使用这个简单的想法就可以获得相当好的性能:
public class ExampleHashSet<T>
{
const int ConcurrencyLevel = 124;
const int Lower31BitMask = 0x7FFFFFFF;
HashSet<T>[] sets = new HashSet<T>[ConcurrencyLevel];
IEqualityComparer<T> comparer;
public ExampleHashSet()
{
comparer = EqualityComparer<T>.Default;
for(int i = 0; i < ConcurrencyLevel; i++)
sets[i] = new HashSet<T>();
}
public bool Add(T item)
{
int hash = (comparer.GetHashCode(item) & Lower31BitMask) % ConcurrencyLevel;
lock(sets[hash])
{
return sets[hash].Add(item);
}
}
public bool Remove(T item)
{
int hash = (comparer.GetHashCode(item) & Lower31BitMask) % ConcurrencyLevel;
lock(sets[hash])
{
return sets[hash].Remove(item);
}
}
// further methods ...
}
系统的HashSet是包装的，但与其他答案不同的是，我们对多个答案持有锁 hashset。不同的线程能够在不同的hashset上“工作”，从而降低了总体等待时间。
这个想法可以在HashSet本身中被概括和直接实现(持有桶上的锁，而不是锁) 成套)。这里可以找到一个例子。
其他回答
我基于ConcurrentDictionary创建了一个实际的ConcurrentHashSet，而不是包装ConcurrentDictionary或锁定HashSet。
这个实现支持每个项目的基本操作，而不需要HashSet的set操作，因为它们在并发场景中没有意义:
var concurrentHashSet = new ConcurrentHashSet<string>(
new[]
{
"hamster",
"HAMster",
"bar",
},
StringComparer.OrdinalIgnoreCase);
concurrentHashSet.TryRemove("foo");
if (concurrentHashSet.Contains("BAR"))
{
Console.WriteLine(concurrentHashSet.Count);
}
输出:2
你可以从NuGet这里得到它，在GitHub这里看到源代码。
我发现既不能简单地锁定System.Collections.Generic的添加和删除方法。HashSet，或者包装框架的ConcurrentDictionary在需要良好性能的“高吞吐量”场景中是足够的。
通过使用这个简单的想法就可以获得相当好的性能:
public class ExampleHashSet<T>
{
const int ConcurrencyLevel = 124;
const int Lower31BitMask = 0x7FFFFFFF;
HashSet<T>[] sets = new HashSet<T>[ConcurrencyLevel];
IEqualityComparer<T> comparer;
public ExampleHashSet()
{
comparer = EqualityComparer<T>.Default;
for(int i = 0; i < ConcurrencyLevel; i++)
sets[i] = new HashSet<T>();
}
public bool Add(T item)
{
int hash = (comparer.GetHashCode(item) & Lower31BitMask) % ConcurrencyLevel;
lock(sets[hash])
{
return sets[hash].Add(item);
}
}
public bool Remove(T item)
{
int hash = (comparer.GetHashCode(item) & Lower31BitMask) % ConcurrencyLevel;
lock(sets[hash])
{
return sets[hash].Remove(item);
}
}
// further methods ...
}
系统的HashSet是包装的，但与其他答案不同的是，我们对多个答案持有锁 hashset。不同的线程能够在不同的hashset上“工作”，从而降低了总体等待时间。
这个想法可以在HashSet本身中被概括和直接实现(持有桶上的锁，而不是锁) 成套)。这里可以找到一个例子。
您的实现是正确的。不幸的是，. net框架没有提供内置并发哈希集类型。然而，有一些变通办法。
ConcurrentDictionary最后(推荐)
第一个是在命名空间System.Collections.Concurrent中使用类ConcurrentDictionary<TKey, TValue>。在这种情况下，值是没有意义的，所以我们可以使用一个简单的字节(内存中的1个字节)。
private ConcurrentDictionary<string, byte> _data;
这是推荐的选项，因为该类型是线程安全的，并且提供了与HashSet<T>相同的优点，除非key和value是不同的对象。
资料来源:社会化MSDN
Self-implementation
最后，正如您所做的，您可以实现自己的数据类型，使用锁或其他。net提供的线程安全的方法。这里有一个很好的例子:如何在。net中实现ConcurrentHashSet
这个解决方案的唯一缺点是类型HashSet<T>不能正式并发访问，即使是读取操作。
我引用了链接帖子的代码(最初由Ben Mosher编写)。
using System;
using System.Collections.Generic;
using System.Threading;
namespace BlahBlah.Utilities
{
public class ConcurrentHashSet<T> : IDisposable
{
private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim(LockRecursionPolicy.SupportsRecursion);
private readonly HashSet<T> _hashSet = new HashSet<T>();
#region Implementation of ICollection<T> ...ish
public bool Add(T item)
{
_lock.EnterWriteLock();
try
{
return _hashSet.Add(item);
}
finally
{
if (_lock.IsWriteLockHeld) _lock.ExitWriteLock();
}
}
public void Clear()
{
_lock.EnterWriteLock();
try
{
_hashSet.Clear();
}
finally
{
if (_lock.IsWriteLockHeld) _lock.ExitWriteLock();
}
}
public bool Contains(T item)
{
_lock.EnterReadLock();
try
{
return _hashSet.Contains(item);
}
finally
{
if (_lock.IsReadLockHeld) _lock.ExitReadLock();
}
}
public bool Remove(T item)
{
_lock.EnterWriteLock();
try
{
return _hashSet.Remove(item);
}
finally
{
if (_lock.IsWriteLockHeld) _lock.ExitWriteLock();
}
}
public int Count
{
get
{
_lock.EnterReadLock();
try
{
return _hashSet.Count;
}
finally
{
if (_lock.IsReadLockHeld) _lock.ExitReadLock();
}
}
}
#endregion
#region Dispose
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
if (_lock != null)
_lock.Dispose();
}
~ConcurrentHashSet()
{
Dispose(false);
}
#endregion
}
}
EDIT:将入口锁方法移到try块之外，因为它们可以抛出异常并执行finally块中包含的指令。
ConcurrentBag(不建议)
不建议使用ConcurrentBag<T>，因为这种类型只允许以线程安全的方式插入给定的元素和删除随机元素。这个类是为促进生产者-消费者场景而设计的，这不是OP的目标(更多解释在这里)。
其他操作(例如，扩展方法提供的操作)不支持并发使用。MSDN文档警告:“ConcurrentBag的所有公共和受保护成员都是线程安全的，可以从多个线程并发使用。然而，通过ConcurrentBag实现的接口之一访问的成员，包括扩展方法，不保证是线程安全的，可能需要由调用者同步。”
使ISet<T>并发的棘手之处在于集合方法(并、交、差)本质上是迭代的。至少，您必须遍历操作中涉及的一个集合的所有n个成员，同时锁定两个集合。
当您必须在迭代期间锁定整个集合时，您将失去ConcurrentDictionary<T,byte>的优势。如果没有锁定，这些操作就不是线程安全的。
考虑到ConcurrentDictionary<T,byte>所增加的开销，使用权重较轻的HashSet<T>并将所有内容都锁起来可能更明智。
如果您不需要设置操作，则使用ConcurrentDictionary<T，字节>，并且在添加键时仅使用default(byte)作为值。
由于没有人提到它，我将提供另一种方法，可能适合也可能不适合你的特定目的:
微软不可变集合
来自微软团队的一篇博客文章:
While creating and running concurrently is easier than ever, one of the fundamental problems still exists: mutable shared state. Reading from multiple threads is typically very easy, but once the state needs to be updated, it gets a lot harder, especially in designs that require locking. An alternative to locking is making use of immutable state. Immutable data structures are guaranteed to never change and can thus be passed freely between different threads without worrying about stepping on somebody else’s toes. This design creates a new problem though: How do you manage changes in state without copying the entire state each time? This is especially tricky when collections are involved. This is where immutable collections come in.
这些集合包括ImmutableHashSet<T>和immutableelist <T>。
性能
由于不可变集合在底层使用树数据结构来支持结构共享，因此它们的性能特征不同于可变集合。当与锁定可变集合进行比较时，结果将取决于锁争用和访问模式。然而，摘自另一篇关于不可变集合的博客文章:
Q: I’ve heard that immutable collections are slow. Are these any different? Can I use them when performance or memory is important? A: These immutable collections have been highly tuned to have competitive performance characteristics to the mutable collections while balancing memory sharing. In some cases they are very nearly as fast as the mutable collections both algorithmically and in actual time, sometimes even faster, while in other cases they are algorithmically more complex. In many cases however the difference will be negligible. Generally you should use the simplest code to get the job done and then tune for performance as necessary. The immutable collections help you write simple code, especially when thread-safety has to be considered.
换句话说，在许多情况下，差异不会被注意到，您应该选择更简单的选择——对于并发集，将使用ImmutableHashSet<T>，因为您没有现有的锁定可变实现!: -)
