我所知道的HttpContext.Current

在MVC中，HttpContext.Current是比較常見的對象，可以用它來進行Session，Cache等的保存等。但是它並不是無處不在的，下面就慢慢來揭開它的面紗。

當我們向服務端發送請求的時候，頁面會響應我們的請求，比如我們訪問A頁面，那么服務端就會把A頁面通過處理后返回給我們，訪問B頁面，過程同樣。在這里，我們訪問A頁面和訪問B頁面，總共進行了2次請求，這兩次請求會不會是在同一個頁面線程中呢？因為Asp.net模型本身就是多線程模式的,那么讓我們來做一個實驗：

首先,創建一個Asp.net項目,新建一個Default.aspx主頁面,然后新建一個About.aspx從頁面,在Default.aspx頁面中,代碼如下:

protected void Page_Load(object sender, EventArgs e)
{
     Response.Write("Default頁面線程ID：" + Thread.CurrentThread.ManagedThreadId);
     HttpContext.Current.Cache.Insert("test", "TestValue", null, DateTime.Now.AddMinutes(120),System.Web.Caching.Cache.NoSlidingExpiration);
}

在代碼中,我們打印出了當前頁面的線程ID並做了一個簡單的緩存.

在About.aspx頁面中,代碼如下:

 protected void Page_Load(object sender, EventArgs e)
 {
     bool flag = HttpContext.Current == null;
     Response.Write("About頁面線程ID：" + Thread.CurrentThread.ManagedThreadId.ToString(+"<br/>");
     Response.Write("About頁面的Httpcontext對象："+(flag?"未創建":"已經創建")+"<br/>");
     Response.Write("About頁面獲取的緩存值為："+HttpContext.Current.Cache["test"]+"<br/>");
}

在代碼中,我們同樣打印出了當前頁面的線程ID並獲取之前的緩存:

得到的結果如下:

Default頁面線程ID：4

 

About頁面線程ID：8
About頁面的Httpcontext對象：已經創建
About頁面獲取的緩存值為：TestValue

從代碼輸出結果，我們可以看出，兩次請求分別被不同的線程處理，HttpContext.Current在這兩個線程中是可用的，為什么跨線程后還能夠使用呢？這個后面我們再來講解。

下面再看兩個例子，在APM模式處理中和子線程處理中，看看HttpContext.Current是否依然能夠訪問：

首先是APM模式的例子：

private void DO()
{
      System.Threading.Thread.Sleep(1000);
      Response.Write(HttpContext.Current==null?"沒有創建":"已經創建");
}

private void BeginDO()
{
      Action action = new Action(DO);
      action.BeginInvoke((iar) =>
      {
          Action endAction = (Action)iar.AsyncState;
           endAction.EndInvoke(iar);
      }, action);
}

做好之后，讓我們運行起來，結果在執行

Response.Write(HttpContext.Current==null?"沒有創建":"已經創建");

這句話的時候報錯，提示：響應在此上下文中不可用。看來，在APM中，是不可用的。

那么在子線程中呢？

private void ThreadDo()
{
     new Thread(new ThreadStart(DO)).Start();
}

讓我們執行，看看結果，不幸的是，當執行到同樣那句話的時候報錯，提示：響應在此上下文中不可用。

為什么在頁面中，跨線程可用，但是在APM模式或者是創建了子線程的場景中不能用呢？

就讓我們來剖析一下源代碼：

首先，HttpContext.Current源碼：

// System.Web.HttpContext
/// <summary>Gets or sets the <see cref="T:System.Web.HttpContext" /> object for the current HTTP request.</summary>
/// <returns>The <see cref="T:System.Web.HttpContext" /> for the current HTTP request.</returns>
public static HttpContext Current
{
   get
   {
      return ContextBase.Current as HttpContext;
   }
   set
   {
      ContextBase.Current = value;
   }
}

我們看到，是通過ContextBase.Current返回，讓我們繼續深究下去：

// System.Web.Hosting.ContextBase
internal static object Current
{
   get
   {
      return CallContext.HostContext;
   }
   [SecurityPermission(SecurityAction.Demand, Unrestricted = true)]
   set
   {
      CallContext.HostContext = value;
   }
}

走到這里我們看到，是通過CallContext.HostContext對象返回，繼續深究：

// System.Runtime.Remoting.Messaging.CallContext
/// <summary>Gets or sets the host context associated with the current thread.</summary>
/// <returns>The host context associated with the current thread.</returns>
/// <exception cref="T:System.Security.SecurityException">The immediate caller does not have infrastructure permission. </exception>
public static object HostContext
{
    [SecurityCritical]
    get
    {
        IllogicalCallContext illogicalCallContext = Thread.CurrentThread.GetIllogicalCallContext();
        object hostContext = illogicalCallContext.HostContext;
        if (hostContext == null)
        {
            LogicalCallContext logicalCallContext = CallContext.GetLogicalCallContext();
            hostContext = logicalCallContext.HostContext;
        }
        return hostContext;
    }
    [SecurityCritical]
    set
    {
        if (value is ILogicalThreadAffinative)
        {
            IllogicalCallContext illogicalCallContext = Thread.CurrentThread.GetIllogicalCallContext();
            illogicalCallContext.HostContext = null;
            LogicalCallContext logicalCallContext = CallContext.GetLogicalCallContext();
            logicalCallContext.HostContext = value;
            return;
        }
        LogicalCallContext logicalCallContext2 = CallContext.GetLogicalCallContext();
        logicalCallContext2.HostContext = null;
        IllogicalCallContext illogicalCallContext2 = Thread.CurrentThread.GetIllogicalCallContext();
        illogicalCallContext2.HostContext = value;
    }
}

看到了什么？從字面意思，我們可以看到：如果當前線程中存在與之相關的對象，則直接返回，否則就創建一個關聯的對象並返回。

那么，也就是說，雖然請求的頁面的線程變了，但是由於HttpContext.Current被當做相關對象被創建，所以可以在不同的頁面中獲取其實例。

但是為什么在APM模式或者子線程場景中不能訪問呢？由於APM模式或者子線程場景的處理是被操作系統所接管，因為apm模式需要操作系統分配線程來進行異步處理，子線程也是由操作系統調配，這些與當前的請求已經沒有關系，所以會出現無響應的情況。下面一幅圖代表我對這個的理解：

另外，引用一下Fish-li的文章，Httpcontext.current在如下場景中是不可用的，我們看到，這些場景操作都是被操作系統所接管：

1. 定時器的回調。
2. Cache的移除通知。
3. APM模式下異步完成回調。
4. 主動創建線程或者將任務交給線程池來執行。

最后，有人說，那我可以把HttpContext.current對象全局緩存，然后放到子線程中使用可以么？我只能說，仍然不可以，仍然會出現“響應在此上下文中不可用”的錯誤提示。你不信可以試試看。

由於HttpContext.Current對象會被關聯創建，所以，全局緩存他是沒必要的。