C# HttpRuntime.Cache 最佳实践
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/754661/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
HttpRuntime.Cache best practices
提问by Andrew Harry
In the past I have put a lock around accessing the HttpRuntime.Cache mechanism. I'm not sure if I had really researched the issue in the past and blindy surrounded it with a lock.
过去，我对访问 HttpRuntime.Cache 机制设置了锁定。我不确定我过去是否真的研究过这个问题，并且盲目地用锁将其包围。
Do you think this is really necessary?
你觉得这真的有必要吗？
回答by j3r03nq
According to this documentation http://msdn.microsoft.com/en-us/library/system.web.caching.cache(VS.80).aspxaccess to the cache object is thread safe. As for the object(s) you store in the cache thread safety has to come from somewhere else.
根据这个文档http://msdn.microsoft.com/en-us/library/system.web.caching.cache(VS.80).aspx对缓存对象的访问是线程安全的。至于您存储在缓存中的对象，线程安全必须来自其他地方。
回答by CraigTP
I don't think it's necessary to wrap access to the HttpRuntime.Cache property with a lock, as the .Cache property is static and also thread-safe.
我认为没有必要用锁来包装对 HttpRuntime.Cache 属性的访问，因为 .Cache 属性是静态的，也是线程安全的。
There are many different ways of accessing the Cache object (HttpRuntime.Cache, HttpContext.Current.Cache, Page.Cache etc.). They all access the same Cache object, as there's only one Cache object per Application Domain, as it's effectively a thread-safe Singleton object.
访问 Cache 对象的方式有很多种（HttpRuntime.Cache、HttpContext.Current.Cache、Page.Cache 等）。它们都访问同一个 Cache 对象，因为每个应用程序域只有一个 Cache 对象，因为它实际上是一个线程安全的 Singleton 对象。
回答by frankadelic
This article suggests a lock should be used:
这篇文章建议应该使用锁：
http://msdn.microsoft.com/en-us/magazine/cc500561.aspx
http://msdn.microsoft.com/en-us/magazine/cc500561.aspx
Quote:
引用：
The problem is that if you've got a query that takes 30 seconds and you're executing the page every second, in the time it takes to populate the cache item, 29 other requests will come in, all of which will attempt to populate the cache item with their own queries to the database. To solve this problem, you can add a thread lock to stop the other page executions from requesting the data from the database.
问题是，如果您有一个需要 30 秒的查询并且您每秒都在执行该页面，那么在填充缓存项所需的时间内，将有 29 个其他请求进入，所有这些请求都将尝试填充缓存项带有自己对数据库的查询。为了解决这个问题，您可以添加一个线程锁来阻止其他页面执行从数据库请求数据。
Here is their code snippet:
这是他们的代码片段：
// 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;
}
}
}
I haven't tested this code, but I would be very interested to hear someone who has evaluated this approach in a production environment.
我还没有测试过这个代码，但我很想听到有人在生产环境中评估过这种方法。
回答by Liong Ng
I don't think locking is the answer to the issue below, especially in the production environment, where you have several servers running your application.
我不认为锁定是以下问题的答案，尤其是在生产环境中，您有多个服务器运行您的应用程序。
The problem is that if you've got a query that takes 30 seconds and you're executing the page every second, in the time it takes to populate the cache item, 29 other requests will come in, all of which will attempt to populate the cache item with their own queries to the database. To solve this problem, you can add a thread lock to stop the other page executions from requesting the data from the database.
问题是，如果您有一个需要 30 秒的查询并且您每秒都在执行该页面，那么在填充缓存项所需的时间内，将有 29 个其他请求进入，所有这些请求都将尝试填充缓存项带有自己对数据库的查询。为了解决这个问题，您可以添加一个线程锁来阻止其他页面执行从数据库请求数据。
