HttpRuntime.Cache最佳實踐

Question

在過去，我已經鎖定訪問HttpRuntime.Cache機制。 我不確定過去是否真的研究過這個問題，並且盲目地用鎖鎖住了它。

您認爲這是非常必要的嗎？

Answer 1

根據此文檔http://msdn.microsoft.com/en-us/library/system.web.caching.cache(VS.80).aspx訪問緩存對象是線程安全的。 至於你存儲在緩存線程中的對象，安全性必須來自其他地方。

Answer 2

我不認爲有必要用一個鎖來包裝對HttpRuntime.Cache屬性的訪問，因爲.Cache屬性是靜態的，也是線程安全的。

訪問Cache對象有許多不同的方式（HttpRuntime.Cache，HttpContext.Current.Cache，Page.Cache等）。它們都訪問同一個Cache對象，因爲每個Application Domain只有一個Cache對象，因爲它實際上是一個線程安全的Singleton對象。

Answer 3

本文提出了一種鎖應該使用：

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 4

我不認爲鎖定是下面問題的答案，特別是在生產環境中，您有幾臺服務器運行您的應用程序。

問題是，如果你有一個需要30秒的查詢，並且你每秒執行一次頁面，在填充緩存項目所需的時間內，將會有29個其他請求進入，所有這些請求將嘗試用自己的查詢填充緩存項目到數據庫。爲了解決這個問題，你可以添加一個線程鎖來停止其他頁面執行從數據庫請求數據。