锁定一个实习字符串？

Question

更新：如果此方法不是线程安全的，这是可以接受的，但我有兴趣了解如何使其线程安全。另外，如果可以避免的话，我不想为 key 的所有值锁定单个对象。

原始问题：假设我想编写一个高阶函数，它接受一个键和一个函数，并检查是否已使用给定键缓存对象。如果有，则返回缓存的值。否则，运行给定的函数并缓存并返回结果。

这是我的代码的简化版本：

public static T CheckCache<T>(string key, Func<T> fn, DateTime expires)
{
    object cache = HttpContext.Current.Cache.Get(key);
    //clearly not thread safe, two threads could both evaluate the below condition as true
    //what can I lock on since the value of "key" may not be known at compile time?
    if (cache == null)
    {
        T result = fn();
        HttpContext.Current.Cache.Insert(key, result, null, expires, Cache.NoSlidingExpiration);
        return result;
    }
    else
        return (T)cache;
}

另外，假设我在编译时不知道 key 的所有可能值。

我怎样才能保证这个线程安全？我知道我需要在这里引入锁定，以防止 1+ 个线程将我的条件评估为 true，但我不知道要锁定什么。我读过的许多有关锁定的示例（例如 Jon Skeet 的文章）建议使用仅用于锁定的“虚拟”私有变量。在这种情况下这是不可能的，因为键在编译时是未知的。我知道我可以通过为每个key使用相同的锁来轻松地使该线程安全，但这可能会造成浪费。

现在，我的主要问题是：

是否可以锁定密钥？字符串实习在这里有帮助吗？

阅读后。 NET 2.0 字符串实习，我知道我可以显式调用 String.Intern() 来获取从字符串值到实例的 1 对 1 映射一个字符串。 这样适合加锁吗？我们把上面的代码改成：

public static T CheckCache<T>(string key, Func<T> fn, DateTime expires)
{
    //check for the scenario where two strings with the same value are stored at different memory locations
    key = String.Intern(key); 
    lock (key) //is this object suitable for locking?
    {
        object cache = HttpContext.Current.Cache.Get(key);
        if (cache == null)
        {
            T result = fn();
            HttpContext.Current.Cache.Insert(key, result, null, expires, Cache.NoSlidingExpiration);
            return result;
        }
        else
            return (T)cache;
    }
}

上面的实现线程安全吗？

Answer 1

@wsanville 自己的解决方案的问题，之前部分提到过：

1. 代码库的其他部分可能出于不同目的锁定相同的内部字符串实例，如果幸运的话，只会导致性能问题，如果不幸的话，则会导致死锁（可能仅在将来，随着代码库的增长，由不知道您的 String.Intern 锁定模式的编码人员进行扩展） - 请注意，这包括对同一 interned 字符串的锁定 即使它们位于不同的 AppDomains，可能会导致跨 AppDomain 死锁，
2. 如果您决定这样做，您不可能回收暂存内存
3. String.Intern() 很慢

要解决所有这 3 个问题，您可以实现您自己的 Intern() 您的特定锁定目的，即不要将其用作全局通用字符串内部：

private static readonly ConcurrentDictionary<string, string> concSafe = 
    new ConcurrentDictionary<string, string>();
static string InternConcurrentSafe(string s)
{
    return concSafe.GetOrAdd(s, String.Copy);
}

我将此方法称为...Safe()，因为实习时我不会存储传入的 String 实例，因为例如，可能是一个已经驻留的String，使其受到上面1.中提到的问题的影响。

为了比较各种驻留字符串方法的性能，我还尝试了以下两种方法以及String.Intern。

private static readonly ConcurrentDictionary<string, string> conc = 
    new ConcurrentDictionary<string, string>();
static string InternConcurrent(string s)
{
    return conc.GetOrAdd(s, s);
}

private static readonly Dictionary<string, string> locked = 
    new Dictionary<string, string>(5000);
static string InternLocked(string s)
{
    string interned;
    lock (locked)
        if (!locked.TryGetValue(s, out interned))
            interned = locked[s] = s;
    return interned;
}

---

基准测试

100 个线程，每个线程随机选择 5000 个不同字符串（每个字符串包含 8 位数字）之一 50000 次，然后调用各自的 intern 方法。所有值均在充分预热后。这是 Windows 7，64 位，4 核 i5。

注意：预热上述设置意味着预热后，不会对相应的实习字典进行任何写入，而只会读取。这是我对当前用例感兴趣的内容，但不同的写入/读取比率可能会影响结果。

结果

• String.Intern(): 2032 毫秒
• InternLocked(): 1245 毫秒
• InternConcurrent(): 458 毫秒
• < code>InternConcurrentSafe(): 453 ms

事实上，InternConcurrentSafe 与 InternConcurrent 一样快，这是有道理的，因为事实上，这些数字是在预热之后的（请参见上面的注意），因此在测试期间实际上没有或只有几次 String.Copy 调用。

---

In order to properly encapsulate this, create a class like this:

public class StringLocker
{
    private readonly ConcurrentDictionary<string, string> _locks =
        new ConcurrentDictionary<string, string>();

    public string GetLockObject(string s)
    {
        return _locks.GetOrAdd(s, String.Copy);
    }
}

在为您可能拥有的每个用例实例化一个 StringLocker 后，就像调用

lock(myStringLocker.GetLockObject(s))
{
    ...

---

NB

一样简单。再想一想，不需要返回 < 类型的对象code>string 如果你只想锁定它，那么复制字符是完全没有必要的，下面的类会比上面的类表现得更好。

public class StringLocker
{
    private readonly ConcurrentDictionary<string, object> _locks =
        new ConcurrentDictionary<string, object>();

    public object GetLockObject(string s)
    {
        return _locks.GetOrAdd(s, k => new object());
    }
}

Answer 2

Daniel 的变体答案...

而不是为每个字符串创建一个新的锁对象，您可以共享一小部分锁，根据字符串的哈希码选择要使用的锁。如果您可能拥有数千或数百万个密钥，这将意味着 GC 压力更小，并且应该允许足够的粒度以避免任何严重的阻塞（如果需要，可能在进行一些调整之后）。

public static T CheckCache<T>(string key, Func<T> fn, DateTime expires)
{
    object cached = HttpContext.Current.Cache[key];
    if (cached != null)
        return (T)cached;

    int stripeIndex = (key.GetHashCode() & 0x7FFFFFFF) % _stripes.Length;

    lock (_stripes[stripeIndex])
    {
        T result = fn();
        HttpContext.Current.Cache.Insert(key, result, null, expires,
                                         Cache.NoSlidingExpiration);
        return result;
    }
}

// share a set of 32 locks
private static readonly object[] _stripes = Enumerable.Range(0, 32)
                                                      .Select(x => new object())
                                                      .ToArray();

这将允许您通过更改 _stripes 数组中的元素数量来调整锁定粒度以满足您的特定需求。 （但是，如果您需要接近每串一锁的粒度，那么您最好采用丹尼尔的答案。）

Answer 3

切勿锁定琴弦。特别是那些被拘留的人。请参阅 此博客条目介绍了锁定驻留字符串的危险。

只需创建一个新对象并锁定它：

object myLock = new object();

Answer 4

根据文档，缓存类型是线程安全的。因此，不同步自己的缺点是，当创建该项目时，在其他线程意识到它们不需要创建它之前，可能会创建它几次。

如果情况只是为了缓存常见的静态/只读内容，那么不必费心去同步，只是为了保存可能发生的少数冲突。 （假设冲突是良性的。）

锁定对象不会特定于字符串，它将特定于您所需的锁定的粒度。在这种情况下，您尝试锁定对缓存的访问，因此一个对象将服务锁定缓存。锁定传入的特定密钥的想法不是锁定通常关注的概念。

如果您想阻止多次发生昂贵的调用，那么您可以将加载逻辑剥离到新类 LoadMillionsOfRecords 中，调用 .Load 并在内部锁定上锁定一次根据奥德的回答反对。

Answer 5

我会采用务实的方法并使用虚拟变量。
如果出于某种原因这是不可能的，我将使用 Dictionary ，其中 key 作为键，虚拟对象作为值，并锁定该值，因为字符串不适合锁定：

private object _syncRoot = new Object();
private Dictionary<string, object> _syncRoots = new Dictionary<string, object>();

public static T CheckCache<T>(string key, Func<T> fn, DateTime expires)
{
    object keySyncRoot;
    lock(_syncRoot)
    {

        if(!_syncRoots.TryGetValue(key, out keySyncRoot))
        {
            keySyncRoot = new object();
            _syncRoots[key] = keySyncRoot;
        }
    }
    lock(keySyncRoot)
    {

        object cache = HttpContext.Current.Cache.Get(key);
        if (cache == null)
        {
            T result = fn();
            HttpContext.Current.Cache.Insert(key, result, null, expires, 
                                             Cache.NoSlidingExpiration);
            return result;
        }
        else
            return (T)cache;
    }
}

但是，在大多数情况下，这是矫枉过正和不必要的微优化。

Answer 6

我在 Bardock.Utils 包中添加了一个解决方案，灵感来自 @eugene-beresovsky 答案。

用法：

private static LockeableObjectFactory<string> _lockeableStringFactory = 
    new LockeableObjectFactory<string>();

string key = ...;

lock (_lockeableStringFactory.Get(key))
{
    ...
}

解决方案代码 :

namespace Bardock.Utils.Sync
{
    /// <summary>
    /// Creates objects based on instances of TSeed that can be used to acquire an exclusive lock.
    /// Instanciate one factory for every use case you might have.
    /// Inspired by Eugene Beresovsky's solution: https://stackoverflow.com/a/19375402
    /// </summary>
    /// <typeparam name="TSeed">Type of the object you want lock on</typeparam>
    public class LockeableObjectFactory<TSeed>
    {
        private readonly ConcurrentDictionary<TSeed, object> _lockeableObjects = new ConcurrentDictionary<TSeed, object>();

        /// <summary>
        /// Creates or uses an existing object instance by specified seed
        /// </summary>
        /// <param name="seed">
        /// The object used to generate a new lockeable object.
        /// The default EqualityComparer<TSeed> is used to determine if two seeds are equal. 
        /// The same object instance is returned for equal seeds, otherwise a new object is created.
        /// </param>
        public object Get(TSeed seed)
        {
            return _lockeableObjects.GetOrAdd(seed, valueFactory: x => new object());
        }
    }
}