这是清除 C# MemoryCache 的好方法吗？

Question

我已阅读有关在 C# 中清除 MemoryCache 的问题和答案。 有很多建议，例如： 1.枚举缓存，并删除所有项目-根据其他人的说法，这不好，获取枚举器会锁定整个事物，并且会发生各种启示，引用文档的一部分，我没有找到，并且显示警告，我未能重现。无论如何，我认为这不是一个非常有效的解决方案。

1. 将键存储在单独的集合中，并迭代该集合，以从缓存中删除项目。 - 除了这听起来不是很安全，听起来也不是很有效。

2. 处理旧缓存，并创建一个新缓存 - 这听起来不错，这是我想到的明显问题，并且在几个 cmets 中指出，对旧缓存的现有引用可能会带来问题。当然，操作的顺序很重要，你必须为旧的保存一个引用，创建一个新的来代替旧的，然后处理旧的 - 似乎不是每个人都注意到这个细微差别。

那么现在呢？我的一位同事建议使用 MemoryCache 解决我的问题，他将缓存对象包装在另一个类中，它可以选择获取密钥（如果需要，从数据库加载）、删除密钥或清除缓存.前两个现在不重要，第三个很有趣。我为此使用了第三种解决方案，按照“保证，除了我自己的实现之外，没有对 MemoryCache 对象的任何额外引用”。所以相关代码是：

构造函数：

public MyCache()
{
    _cache = new MemoryCache("MyCache");
}

清除缓存：

public void ClearCacheForAllUsers()
{
    var oldCache = _cache;
    _cache = new MemoryCache("MyCache");
    oldCache.Dispose();
}

_cache 是私有的 MemoryCache 对象。

这会在多线程环境中引起问题吗？我对并行调用 read 和 dispose 有一些担忧。我是否应该实现某种锁定机制，允许并发读取，但会导致清除缓存功能等待缓存上的当前读取完成？

我的猜测是肯定的，它是实现这一点所必需的，但在开始之前我想先了解一下。

罗伯特

编辑 1 关于 Voo 的回答： 可以保证，“包装器”（MyCache）之外的任何人都不会获得对 _cache 对象的引用。我的担心是这样的：

T1:
MyCache.ClearAll()
    var oldCache = _cache
T2:
MyCache.GetOrReadFromDb("stuff")
T1:
    _cache=new MemoryCache("MyCache")
    oldCache.Dispose()
T2:
    *something bad*

除了 T2 线程仍在使用旧缓存之外，这不是首选，但我可以忍受，是否存在 Get 方法以某种方式访问​​处于已处置状态的旧缓存或读取新缓存的情况没有数据？

想象一下 GetOrReadFromDb 函数是这样的：

public object GetOrReadFromDb(string key)
{
    if(_cache[key]==null)
    {
        //Read stuff from DB, and insert into the cache
    }
    return _cache[key];
}

我认为有可能，控制从读取线程中移除，并给予清除，例如在从 db 读取之后，在返回 _chache[key] 值之前，这可能会导致问题.这是一个真正的问题吗？

Answer 1

您的解决方案的问题在于它引入了可能的竞争条件，需要丑陋的锁或其他线程同步解决方案。

改为使用内置解决方案。

您可以使用自定义 ChangeMonitor 类从缓存中清除您的项目。您可以将ChangeMonitor 实例添加到调用MemoryCache.Set 时设置的CacheItemPolicy 的ChangeMonitors 属性。

例如：

class MyCm : ChangeMonitor
{
    string uniqueId = Guid.NewGuid().ToString();

    public MyCm()
    {
        InitializationComplete();
    }

    protected override void Dispose(bool disposing) { }

    public override string UniqueId
    {
        get { return uniqueId; }
    }

    public void Stuff()
    {
        this.OnChanged(null);
    }
}

使用示例：

        var cache = new MemoryCache("MyFancyCache");
        var obj = new object();
        var cm = new MyCm();
        var cip = new CacheItemPolicy();
        cip.ChangeMonitors.Add(cm);

        cache.Set("MyFancyObj", obj, cip);

        var o = cache.Get("MyFancyObj");
        Console.WriteLine(o != null);

        o = cache.Get("MyFancyObj");
        Console.WriteLine(o != null);

        cm.Stuff();

        o = cache.Get("MyFancyObj");
        Console.WriteLine(o != null);

        o = cache.Get("MyFancyObj");
        Console.WriteLine(o != null);

Answer 2

从未使用过MemoryCache 类，但存在明显的竞争条件。当另一个线程 T2 正在执行 ClearCacheForAllUsers 时，线程 T1 可能会调用 GetElement（或您所称的任何名称）。

那么可能会发生以下情况：

T1:
reg = _cache
T2:
oldCache = _cache
_cache = new MemoryCache("MyCache")
oldCache.Dispose()
T1:
reg.Get()   // Ouch bad! Dispose tells us this results in "unexpected behavior"

简单的解决方案是引入同步。

如果锁定是不可接受的，您可以使用一些巧妙的技巧，但最简单的解决方案是使用Finalize 我会说。当然，这通常是个坏主意，但是假设缓存唯一要做的就是用完内存，因此仅在内存压力下收集缓存并没有什么坏处，您可以通过让 GC 担心来避免担心竞争条件关于它。请注意，_cache 必须是可变的。

另一种可能的方法是，作为实现细节Get 显然总是在缓存被处理后返回null。在这种情况下，您可以避免在大多数情况下锁定，除非在这些罕见的情况下。虽然这是实现定义的，但我个人不想依赖这么小的细节。