引用 MSDN 关于 System.Web.HttpApplication 的内容
引用自 http://msdn.microsoft.com/en-us/library/ 4wt3wttw.aspx：
HttpApplication 的一个实例 类用于处理许多请求 在它的一生中。然而，它可以 一次仅处理一个请求。 因此，成员变量可用于 存储每个请求的数据。
为什么按请求？也许每组请求？似乎成员变量可以用于在 HttpApplication 的整个生命周期中存储数据。因此，第二个（对于此 HttpApplication）请求开始时 HttpApplication 的状态等于第一个（对于此 HttpApplication）请求结束时的状态。
为什么按请求？
Quote from http://msdn.microsoft.com/en-us/library/4wt3wttw.aspx:
One instance of the HttpApplication
class is used to process many requests
in its lifetime. However, it can
process only one request at a time.
Thus, member variables can be used to
store per-request data.
Why per-request? Maybe per set of requests? Seems that member variables can be used to store data during full lifecycle of HttpApplication. Thus state of HttpApplication at the beginning of second (for this HttpApplication) request is equal to the state at the end of first (for this HttpApplication) request.
Why per-request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
每当涉及 IIS 时，请求都会发送给 HttpApplication 实例之一（从 Web 应用程序的应用程序池中选取）。此 HttpApplication 的事件（在 global.asax 中定义）将可供请求使用。
据我了解，如果多个请求可以同时访问 HttpApplication，则会造成不一致。 Asp.Net 本身是一个非常复杂的体系结构，并发性将使其成为真正的噩梦。
每个请求数据的事情有点扭曲，或者我可能没有正确理解这个概念，但我认为这应该意味着在某个时间点 HttpApplication 仅处理一个请求，而不是它可以保存放入其中的变量/值应用程序对象通过一个请求。因为放入 Application 对象中的任何数据都不是针对每个请求的，而是可供所有请求使用。
让我知道这是否是您正在寻找的：
P这是了解 Asp.Net 的最佳链接 (http ://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp)
检查 HttpApplication 部分以更好地理解这一点。
A request whenever it comes to IIS is given to one of the HttpApplication instances (picked from the app. pool of a web app.). The events of this HttpApplication (defined in global.asax) will be available to the request.
From what I understand it'd create inconsistency if multiple requests could access an HttpApplication simulataneously. Asp.Net is in itself a very complex architecture, concurrency would make it a real nightmare to work with.
The per-request data thing is slightly twisted or I may not have gotten the concept right but I think it should mean that at one point in time the HttpApplication is dealing with only one request and not that it can hold variables/values put in the Application object by one request. Because any data put in the Application object is not per-request, rather it's available to all the requests.
Let me know whether this is what you're looking for :P
P.S. Here's the BEST link to understand Asp.Net (http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp)
Check the HttpApplication section to understand this better.
它指出 HttpApplication 对象的成员可用于存储每个请求的数据。这并不意味着成员仅限于每个请求的数据。 HttpApplication.Application 成员保存了对整个应用程序来说是全局的成员，但是在处理请求的过程中，特定的 HttpApplication 实例只能使用当前正在处理的请求中的信息来修改 ApplicationState 对象中保存的全局信息。如果 HttpApplication 对象可以同时访问多个请求，那么可以想象，它将能够通过聚合或从任何请求中选择数据来修改全局数据。正如 @Sidharth Panwar 提到的，这会产生并发问题，并且允许处理多个请求也将是一场噩梦，因为需要保证它们来自同一用户（出于安全/内存原因），而这不能可以保证，因为只要发出新请求，IIS 就会将下一个可用的 HttpApplication 对象排队。这将导致单个实例可能处理大量负载（从而出现瓶颈）。
It's stating that the members of the HttpApplication object can be used to store per-request data. This doesn't mean that the members are restricted to per-request data. The HttpApplication.Application member holds the members that are global to the entire application, but during the processing of the request, the specific HttpApplication instance may only modify the global information kept in the ApplicationState object with the information in the request currently being processed. If the HttpApplication object had access to multiple requests simultaneously, conceivably it would be able to modify global data with aggregate or select data from any of the requests. As @Sidharth Panwar mentioned, this would create concurrency issues, and it would also be a nightmare to allow multiple requests to be processed because they would need to be guaranteed to come from the same user (for security/memory reasons) which can't be guaranteed since IIS queues up the next available HttpApplication object whenever a new request is made. It would lead to a single instance potentially handling a bulk of the load (and thus bottle-necking).