HttpContext.Current 是如何工作的？答案

【问题标题】：How does HttpContext.Current work?HttpContext.Current 是如何工作的？
【发布时间】：2011-03-25 22:08:54
【问题描述】：

这是一个很难表述的问题。我想知道 HttpContext.Current 是如何为每个请求分配一个唯一实例的，因为它是一个静态对象？

谢谢！

【问题讨论】：

【解决方案1】：

Current不是静态变量，它的静态属性，get属性只不过是一个返回当前Context的静态方法。

ASP.NET 使用当前线程存储一些信息，您始终可以获取本地线程存储来存储仅在当前线程中是静态的信息，并且只能通过当前线程中的任何方法访问。

因此 ASP.NET 将一些本地信息存储在 http 上下文执行请求的应用程序的线程中，并且从任何地方调用 Current 将获取本地线程数据并获取所需的信息。

您还可以查看[ThreadStatic] 属性，它的作用方式几乎相似。

更新

从 ASP.NET 4.5 及更高版本开始，Current HttpContext 通过 CallContext 而不是 [ThreadStatic] 传递，因此上下文在单个逻辑上下文而不是当前线程中的所有异步调用中仍然可用，因为每个异步调用都可能结束在不同的线程上。

【讨论】：

除了，它也可以从不同的线程工作（服务相同的请求），这是使用 HttpContext 来存储上下文值而不是使用线程的主要原因
Kelsey 在下面提供了更准确的答案，应该是公认的答案。 HttpContext 不是简单地使用 Thread 来保存的，因为如果你的代码使用 plinq 或 async，它就不会工作，例如
@Sheepy，请看声明，“CallContext 提供的服务非常类似于线程本地存储（除了 CallContext 可以在远程调用期间执行一些额外的魔法）。”而且 HttpContext.Current 也不能与 plinq 和 async 一起使用，而无需编写任何额外的代码。尽管 CallContext 将在内部使用 ThreadLocalStorage，但没有它它就无法工作。因此，请在发表此类评论之前获取所有详细信息。如果您提供 CallContext 不使用 ThreadLocalStorage 的证明，我会同意您的观点。
它确实适用于 plink 和 async，只要它们在请求的范围内执行（而不是在请求完成后挂起）。我之前（plinq）和定期（异步）都尝试过这个，这就是为什么我有兴趣了解它是如何工作的（并且偶然发现了这个线程）。我正在尝试为我正在构建的工具（来自 Java EE 的 .net 的 CDI 实现）实现类似的结果，并且单独使用 Thread 不起作用，现在多线程编程在 .net 中变得非常普遍跨度>

【解决方案2】：

您应该阅读这篇博文：

您应该对以下开头的部分感兴趣。它很长，否则我会引用更多：

我们中间的好奇者会想知道 HttpContext.Current 如何找到当前请求的上下文。

【讨论】：