HttpContext 的线程安全答案

【问题标题】：Thread safety of HttpContextHttpContext 的线程安全
【发布时间】：2012-11-17 17:11:33
【问题描述】：

经过一番谷歌搜索，我没有找到任何关于 HttpContext 线程安全的权威、确凿的信息。

我正在看一个场景，例如：

public class AsyncHandler : IAsyncHttpHandler 
{
   void BeginProcessRequest(...)
   {
      // Spawn some tasks in parallel, provide them with current HttpContext as argument.
   }

   void EndProcessRequest(...) {...}
}

我的（io 绑定）并行任务可能希望同时访问 HttpContext。

环顾各种帖子，似乎这是安全的，但是，我想要一些实际的证据。当然，MSDN 给出了通常的“静态是线程安全的等”，但这并没有帮助，除非我不得不假设它不是线程安全的。

我在 StackOverflow 上看到过各种帖子（例如 here、here 或 here），但对这个问题没有真正的答案。

对于 .NET 4.5 中的所有异步工作，如果 HttpContext 不是线程安全的，这似乎有点奇怪，但是，如果确实不是这样，有什么方法可以做到这一点？我能想到：

克隆它（但这并不容易，尽管乍一看似乎并非不可能）。
包装 HttpContextBase 并使该线程安全（嘿，我称之为 HttpContextWrapperWrapper）。

但这一切都让人觉得有点蹩脚，工作量太大。

编辑：在对此进行了更详细的研究以及稍后的一些反思之后，我相信 HttpContext 不是线程安全的实际上并不重要。我在this 博客文章中对此进行了详细说明。要点是在 ASP.NET 中使用正确的 SynchronizationContext 可确保一次访问上下文的线程不超过一个。

【问题讨论】：

我不认为这是一个明确的情况 - 我认为你需要详细说明你正在考虑执行哪些修改 - 我当然不知道我会做什么 如果多个线程尝试设置/重置相同的响应标头，预计会发生。
我主要考虑的是读取，例如查询参数，而不是设置标题之类的东西。我同意我不知道我会发生什么。同时写入响应流也没有任何意义。

标签： c# asp.net .net multithreading httpcontext

【解决方案1】：

HttpContext 类不是线程安全的。

例如，HttpContext.Items 属性只是对未同步 Hashtable 的引用 - 所以这显然不是线程安全的。

从您的问题中不清楚您希望在并行任务之间共享什么，但我建议您使用自己的线程安全类的实例在任务之间共享状态，而不是尝试包装现有类。

【讨论】：

简单但令人信服的答案，这确实似乎是要走的路。尽管 Items 是一个 IDictionary（因此可能是线程安全的），但它实际上似乎是由 IsSynchronized 属性返回 false 的 HashTable 实现的。