在 IIS 中，如何防止静态成员变量一次被多个请求访问？
我在理解 IIS 如何处理其线程上的静态变量时遇到一些困难。 我的理解一直是，如果 IIS 有 4 个工作进程，那么它可以同时处理 4 个请求，这与有 4 个单独的线程运行网站是一样的。 任何静态变量都将保留在每个单独的线程中。 我有点困惑的原因是我有一个范围来管理连接和缓存事务。 当我测试该应用程序时，我没有注意到任何问题，但在我编译它并从两个不同位置同时点击它之后，我似乎遇到了某种冲突。 现在，如果这些工作进程是分开的，为什么会这样呢？ 一个工作线程可以同时处理多个请求吗？ 这非常重要，因为这些静态成员中保存有唯一的 ID，用于处理管理这些功能的对象的升级，并且它们似乎正在尝试访问同一对象。
我在 x64 机器上的 Vista IIS 服务器上运行它。
编辑
对于需要在单个请求上通过线程保存的值，我将这些值放入 Web.HttpContext.Current.Items 中，这似乎可以解决问题。
可以使用
I’m having some trouble with understanding how IIS is handling static variables on its threads. My understanding has always been that if IIS has 4 worker processes that it can handle 4 requests simultaneously and that it would be the same as having 4 separate threads running the website. Any static variables would persist in each individual thread. The reason I’m a bit confused is that I have a scope that I’ve made which manages connections and caching transactions. When I’m testing the app I don’t notice any issues but after I’ve compiled it and hit it at the same time from two different locations I seem to get a sort of conflict. Now if these worker processes are separate why would this be? Can more than one request be processed on a single worker thread at the same time? This is tremendously important as there are unique ID’s that are held in these static members to handle escalation of the objects that manage these functions and it appears that they are trying to access the same object.
I'm running this on Vista's IIS server on an x64 machine.
EDIT
For values that need to persist through the thread on a single request, I put these values into Web.HttpContext.Current.Items which seems to do the trick.
<ThreadStatic()> can be used but it may not be available during the entirity of the request process. In one module that I have, is only used on a variable to indicate if that thread has already loaded the settings for the cahcing server. If true then the tread (not asp.net) is ready to fetch data from the caching server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
第一个要改变的概念：如果您使用 ASP.NET，它们是 ASP.NET 线程，而不是 IIS 线程。
其次，这是一个 .NET 问题。 静态变量在 .NET 的整个
AppDomain中共享。 由于每个 IIS 应用程序（或多或少）都会有一个AppDomain，这意味着您的静态变量将在应用程序中的所有工作线程之间共享。将会有超过四个线程，并且它们都将共享相同的变量，这意味着您要么需要进行锁定，要么不需要使用静态变量。
无论你一直以来的理解是什么，我建议你回去弄清楚你从哪里得到这种理解； 然后更新一下，因为和ASP.NET没有太大关系。
编辑：主题已经改变，所以我会稍微改变一下答案。
您必须联锁对这些变量的访问。 或者，您应该考虑重新评估您的设计。 您的设计显然假设了一些不同的模型来访问静态数据。 事实证明这个假设是不正确的。 这种假设可能会贯穿您的设计。 您应该根据现实重新评估您的设计。
First concept to change: if you're using ASP.NET, they are ASP.NET threads, not IIS threads.
Second, this is a .NET issue. static variables are shared throughout the
AppDomainin .NET. Since you'll have oneAppDomainper IIS application (more or less), that means your static variables will be shared across all worker threads in the application.There will be a lot more than four threads, and they'll all be sharing the same variables, which means you'll either need to do locking, or you'll need to not use static variables.
Whatever your understanding has always been, I suggest you go back and figure out where you got that understanding from; then update it, because it doesn't have much to do with ASP.NET.
EDIT: The subject has changed, so I'll change the answer a little.
You have to interlock access to these variables. Alternatively, you should consider reevaluating your design. Your design apparently assumed some different model for access to statics. This assumption has turned out not to be correct. It's possible that this assumption may have cascaded throughout your design. You should reevaluate your design in the light of reality.
每个工作进程都在自己的 AppDomain 中运行，因此每个 WP 将有自己的静态变量实例。
在这里的答案中，它建议 AppDomain 在 WP 之间共享，这是不正确的。
不过，您应该使用 .NET 连接池，并且应该研究使用(IDisposable){} 方法来确定连接的范围。
Each worker process runs in its own AppDomain, so each WP will have its own instance of a static variable.
In the answer here it suggests the AppDomain is shared across WPs which is incorrect.
You should be using the .NET connection pooling though and you should investigate the using(IDisposable){} method of scoping your connections.