ASP.NET Core 管道多线程答案

【问题标题】：ASP.NET Core pipeline multithreadingASP.NET Core 管道多线程
【发布时间】：2017-04-10 19:58:23
【问题描述】：

ASP.NET Core 管道是否通过多线程处理请求？如果是这样，您如何配置线程数？另外，单例服务应该是线程安全的吗？

【问题讨论】：

github.com/aspnet/benchmarks 查看结果部分，它回答了您的第一个问题
其实正是这个文件强迫我问这个问题！我可以从这个存储库github.com/aspnet/benchmarks/blob/… 看到这里的线程数是针对客户端应用程序的，而不是针对服务器的！
与上面的纯文本方案类似，但在深度为 16 时启用了 HTTP 流水线。仅包括显示流水线改进的堆栈/服务器。。我怀疑它能否在单个服务器线程上每秒处理 120 万个请求
我来。无论如何，这里真正重要的是开发人员应该如何计算服务器的多线程？
试试 KestrelServerOptions.ThreadCount github.com/aspnet/KestrelHttpServer/blob/dev/src/…

【解决方案1】：

上面的评论已经回答了第一个问题（查看KestrelServerOptions）

关于线程安全，答案在documentation：

单例生命周期服务在第一次被请求时创建（或者如果您在其中指定实例，则在运行 ConfigureServices 时创建），然后每个后续请求都将使用相同的实例。如果您的应用程序需要单例行为，建议允许服务容器管理服务的生命周期，而不是实现单例设计模式并自己在类中管理对象的生命周期。

这意味着对服务的所有请求都拉取同一个对象，这意味着没有每个线程的对象，因此没有线程安全性。

线程安全

单例服务需要是线程安全的。如果单例服务依赖于瞬态服务，则瞬态服务可能还需要是线程安全的，具体取决于单例如何使用它。

再清楚不过了。由于对象不是按线程创建的，因此默认情况下它们不是线程安全的（尽管某些服务可能被设计成这样）。

【讨论】：

对性能有什么影响？如果我们根据一个实例有许多请求进入以运行一些计算怎么办。这不是性能瓶颈吗？
我想这是一个实现细节。不是每个人都知道如何编写正确的多线程代码。 ;) 也就是说，即使它写得正确，很明显你可能有一些请求在等待单例访问，这些请求会延迟到他们获得访问权限。如果这是一个问题，那么不要使用单例！ ;)（尽管在某些情况下可能无法避免，例如更新文件数据）。