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

Question

我已经阅读了有关在C＃中清除MemoryCache的问题以及找到的答案。有许多建议，例如：

1. 枚举缓存并删除所有项目-据其他人称，这不好，获取枚举器会锁定整个东西，所有种类的启示发生，引用部分文档，我没有找到，并显示警告，我无法复制。 无论如何，我认为这不是一个非常有效的解决方案。

2. 将键存储在单独的集合中，并迭代该集合以从缓存中删除项目。 - 除此之外听起来不太线程安全，也不太有效率。

3. 处理旧缓存，并创建一个新缓存-这听起来很好，显然会出现一个问题，并在几条评论中指出，对旧缓存的现有引用可能会带来问题。 当然，操作的顺序很重要，您必须保存旧对象的引用，将新对象创建在旧对象的位置，并处理旧对象-并不是每个人都注意到这个小细节。

那么现在呢？ 我的一位同事建议我使用MemoryCache来解决我的问题，并将缓存对象包装在另一个类中，该类具有获取密钥（如果需要，则从数据库加载），删除密钥或清除缓存的选项。 前两个目前并不重要，第三个则很有趣。 我已经使用此解决方案进行了操作，大致思路是：“保证除我的实现之外，没有任何其他对MemoryCache对象的引用”。 因此，相关代码如下：

构造函数：

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

清除缓存：

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

_cache 是私有的 MemoryCache 对象。

在多线程环境下，这会引起问题吗？我担心并行调用 read 和 dispose。我应该实现一些锁机制，允许并发读取，但导致清除缓存函数等待缓存中当前读取操作结束吗？

我猜是需要实现这个的，但在开始之前，我想获得一些见解。

罗伯特

Voo 的回答上的编辑 1： 可以保证，只有“包装器”（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];
}

我认为可能会出现控制权从读取线程转移到清除线程的情况，例如在从数据库读取后，在返回_chache[key]值之前进行清除，这可能会导致问题。这是一个真正的问题吗？

- Robert

---

请查看https://dev59.com/V2855IYBdhLWcg3wuG0M#22388943。 - Thomas F. Abraham

Answer 1

你的解决方案存在潜在的竞争条件问题，需要使用丑陋的锁或其他线程同步解决方案来解决。

相反，使用内置的解决方案。

你可以使用自定义的 ChangeMonitor 类从缓存中清除项目。当你调用 MemoryCache.Set 时，你可以将 ChangeMonitor 实例添加到 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);

- Venemo

Answer 2

我从未使用过MemoryCache类，但显然存在竞态条件。当一个线程T1调用GetElement（或者你称之为其他什么）时，另一个线程T2正在执行ClearCacheForAllUsers。

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

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。在这种情况下，除了在这些罕见的情况下，你可以避免大部分时间的锁定。虽然这是实现定义的，但我个人不想依赖于这样一个小细节。

- Voo

---

@Robert，我的示例不依赖于类外部的任何引用，因此分析不会改变。 - Voo

在我的实现中，我可以避免获取对自己私有属性的引用。我还可以在该属性上放置大型警告标志，并且如果出现异常情况，我可以修复它。因此，确保不会引用缓存。 - Robert

@Robert 但是你自己代码中的Get实现确实需要引用，这意味着你会遇到竞态条件。如果引用实际上逃离了你的类，无论如何你都输了。 - Voo