这是一个很好的解决方案，以清除c#内存缓存

本文关键字：解决方案 清除 缓存 内存 很好 一个 | 更新日期: 2023-09-27 18:17:52

我已经阅读了关于在c#中清除MemoryCache的问题和答案。有很多建议，比如:1. 枚举缓存，并删除所有项目-根据其他人，这是不好的，得到枚举器锁定整个东西，和各种启示发生，引用部分文档，我没有找到，并显示一个警告，我没有复制。无论如何，我不认为这是一个非常有效的解决方案。

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

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

那现在怎么办?我的一位同事建议使用MemoryCache来解决我的一个问题，他将缓存对象包装在另一个类中，该类可以选择获取键(如果需要的话从db加载)、删除键或清除缓存。前两个现在不重要，第三个很有趣。我为此使用了第三种解决方案，沿着"保证，除了我自己的实现之外，没有对MemoryCache对象的任何额外引用"的路线。相关代码是:

构造函数:

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

ClearCache: 

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]值之前，这可能会导致问题。这真的是个问题吗?

这是一个很好的解决方案，以清除c#内存缓存

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

请使用内置解决方案。

您可以使用自定义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);

从未使用过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。在这种情况下，除了这些罕见的情况外，大多数情况下都可以避免锁定。虽然这是实现定义的，但我个人不喜欢依赖于这样一个小细节。

相关文章：