HttpRuntime.Cache 最佳实践

Question

过去，我对 HttpRuntime.Cache 机制的访问设置了锁定。 我不确定我过去是否真正研究过这个问题，并盲目地用锁包围了它。

您认为这真的有必要吗？

Answer 1

本文建议应使用锁：

http://msdn.microsoft.com /en-us/magazine/cc500561.aspx

引用：

问题是如果你有一个
需要 30 秒的查询，您
每秒执行该页面，在
填充所需的时间
缓存项，29个其他请求将
进来，所有这些都会尝试
用自己的内容填充缓存项
对数据库的查询。 为了解决这个问题
问题，可以加线程锁
停止其他页面执行
从数据库请求数据。

这是他们的代码片段：

// check for cached results
object cachedResults = ctx.Cache["PersonList"];
ArrayList results = new ArrayList();

if  (cachedResults == null)
{
  // lock this section of the code
  // while we populate the list
  lock(lockObject)
  {
    cachedResults = ctx.Cache["PersonList"];
    // only populate if list was not populated by
    // another thread while this thread was waiting
    if (cachedResults == null)
    {
      cachedResults = ...
      ctx.Cache["PersonList"] = cachedResults;
    }
  }
}

我还没有测试过这段代码，但我非常有兴趣听到有人在生产环境中评估了这种方法。

Answer 2

根据此文档 http:// msdn.microsoft.com/en-us/library/system.web.caching.cache(VS.80).aspx 对缓存对象的访问是线程安全的。
至于存储在缓存中的对象，线程安全必须来自其他地方。

Answer 3

我认为没有必要用锁包装对 HttpRuntime.Cache 属性的访问，因为 .Cache 属性是静态的并且也是线程安全的。

访问 Cache 对象的方式有很多种（HttpRuntime.Cache、HttpContext.Current.Cache、Page.Cache 等）。 它们都访问同一个 Cache 对象，因为每个应用程序域只有一个 Cache 对象，因为它实际上是一个线程安全的 Singleton 对象。

Answer 4

我不认为锁定是下面问题的答案，特别是在生产环境中，您有多个服务器运行您的应用程序。

问题是，如果您有一个需要 30 秒的查询，并且每秒都执行该页面，那么在填充缓存项的时间内，将会有 29 个其他请求进入，所有这些请求都会尝试填充缓存项有自己的数据库查询。 为了解决这个问题，您可以添加线程锁来阻止其他页面执行向数据库请求数据。