请求对象属性间歇性地为空答案

【问题标题】：Request Object Properties are null intermittently请求对象属性间歇性地为空
【发布时间】：2018-03-07 22:43:02
【问题描述】：

我的智慧到此为止！我在 IIS 8 Web 服务器上有一个 ASP.NET MVC 应用程序，其中每件事都像冠军一样工作了 3 个月，截至 3 天前突然当代码尝试访问时，我得到随机的空引用异常Request 对象上的任何内容。

我的意思是像 Request.Headers 这样简单的事情会导致抛出 NULL 引用异常。我已经在浏览器中检查了请求正文，并且我的操作团队已经向我发送了请求正文看起来不错的日志。

以前有没有人遇到过这样的事情？我的意思是突然间请求间歇性地具有空属性。例如，有时应用程序加载只是 find 并且用户将执行一些需要在检查标头或访问其他请求属性的地方调用 MVC Action 的事情，当这种情况发生时，它会抛出它，而其他时候它就好了。

【问题讨论】：

你在使用 HttpContext.Current 和 async/threading 吗？
没有异步或线程只调用常规的旧 mvc 操作
想通了，我一时兴起检查了我们的 appPool 设置。出于某种奇怪的原因，它被设置为 18 个工作进程，当它被更改为 1 时，应用程序突然开始工作了。不知道这如何使应用程序变得疯狂，但我会修复。

【解决方案1】：

由于某种奇怪的原因，当我将 AppPool Max 工作进程更改回 1 时，有人将其更改为 18，它突然像冠军一样工作。我不知道为什么 1 个工作进程有效，而 18 个导致各种疯狂的事情发生。

【讨论】：

可能这不是一个修复，但它隐藏了大多数出现的错误。错误仍然存在。使用一名工人通常是正确的选择，但这是一种改进。如果您想要可靠性，请尝试使用 18 个工作人员进行重现并找到错误。
那么错误会出现在代码中吗？我问是因为我们在日志中没有疯狂的异常，直到它被更改的那一天。或者错误会出现在服务器设置中的某个地方？
你是说没有bug？显然有，为什么你的代码会崩溃。工作进程不共享变量。没有由多个工人引起的代码/数据交互。很可能，许多工作人员导致更高的负载和不同的操作系统线程调度暴露了一个不确定的错误。
不是我在问吗？我的意思是每次在代码中的任何位置访问 Request 对象时都会抛出 NRE。