在 ASP .Net Core 3.0 项目中延迟获取工作线程答案

【问题标题】：Delays acquiring worker threads in an ASP .Net Core 3.0 project在 ASP .Net Core 3.0 项目中延迟获取工作线程
【发布时间】：2020-02-18 01:58:05
【问题描述】：

在 ASP .Net Core 3.0 项目中获取工作线程/池线程时，我们的应用程序遇到了延迟。

在较新的语言中，这实际上意味着在生成任务时，Task.Start() 命令与任务执行的第一行代码中之间的时间量。本质上是线程池管理进程创建线程所花费的时间。

需要牢记的一些因素：

    System.Threading.ThreadPool.QueueUserWorkItem(MethodName, e);

    ThreadPool.SetMinThreads(1000, 1000);

【问题讨论】：

您的帖子表明您希望排队操作有效地同步？或者至少是线程的获取/
对您来说什么是“工作线程”？ “获取工作线程时的延迟”是什么意思？请注意，理想的线程数是每个核心 1 个 +（异步/硬件/IO 线程）。添加更多线程不会让你的机器更快（反之，因为系统需要切换等）
@SimonMourier 工作线程是线程池线程，即在我发布的代码中设置的那些。阅读此处了解背景信息：docs.microsoft.com/en-us/dotnet/api/…
@SimonMourier 出于同样的原因，人们可能会关心您的应用程序正在使用多少内存，或者它使用了多少 CPU 时间。您可能不在乎，但是对于运行许多进程的无人值守、长时间运行的服务器应用程序，毫无疑问，可能会出现一个错误，该错误会导致重复的进程泄漏内存，或者生成不退出的任务，从而导致泄漏池线程数。
@SimonMourier 我也认为您从根本上误解了这个问题；你似乎在想我在问 running 线程的性能。事实并非如此，问题很清楚：我正在询问为什么线程池上的线程调度会在 this specific instance 中受到如此过度的延迟 - 并努力描述这一点.

【解决方案1】：

我认为您将 ThreadPool 用于不应该使用的地方。这是官方Silverlight docs 所说的，这很可能也适用于.Net Framework 4：

何时不使用线程池线程

在以下场景中，最好创建和管理自己的线程，而不是使用线程池线程：

您需要在很短的时间内启动多个线程，以执行持续一秒或更长时间的任务。作为其线程管理策略的一部分，线程池在创建线程之前会延迟。因此，当多个任务在短时间内排队时，在所有任务启动之前可能会有很大的延迟。

【讨论】：

但这只发生在这个 Asp.Net Core 3 应用程序上。多年来，我们在 .Net Framework 主机应用程序中使用相同的代码，没有出现这个问题。在这种情况下，对新线程的调用也不是特别高，因此延迟不容易解释。