3

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

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

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

所以现在怎么办？我的一位同事建议使用 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] 值之前，这可能会导致问题。这是一个真正的问题吗？

4

2 回答 2

2

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

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

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

例如：

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);
于 2014-08-13T08:14:53.283 回答
0

从来没有使用过这个MemoryCache类，但是有一个明显的竞争条件。当另一个线程 T2 正在执行时，线程 T1 可能会调用GetElement（或任何您调用的）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在缓存被处理后返回。在这种情况下，您可以在大多数情况下避免锁定，除非在这些罕见的情况下。虽然这是实现定义的，但我个人不想依赖这么小的细节。

于 2014-08-12T17:35:14.287 回答