我有一个关于 .NET 线程池的非常具体的问题。
我想说我对线程池有相当的了解，但有一件事仍然让我困惑。
假设我运行一个 Web 应用程序来处理请求，但也通过渲染/编辑上传的媒体来执行大量 CPU 密集型工作。
在应用程序中分离 I/O 和 CPU 密集型任务时，常见的建议是将 CPU 密集型工作分派到 .Net ThreadPool。Task.Run(...)具体来说，这意味着用- 到目前为止一切顺利来调度呼叫。
但是，我确实想知道，如果针对大量请求执行此操作会发生什么。假设数百/数千个，足以给机器带来巨大的压力，甚至到线程池无法再处理的程度。当您的 CPU 无法处理更多线程时，添加更多线程显然只能到此为止。我想说，此时线程池的线程也受 CPU 本身和调度算法的支配。
这对 I/O 绑定异步操作有何影响？
这是否会导致 I/O 绑定的异步操作在执行其延续时遇到困难？假设我们处于一个在 Threadpool 上执行 async/await 延续并丢弃 SynchronizationContext 的运行时环境中，如何确保这些仍然可以正确执行？
线程池是否对哪个线程接收调度优先级做出任何复杂的假设，以确保吞吐量，即使它完全被工作污染？
了解 ASP.Net Core 如何处理这个问题会特别有趣，因为请求处理程序本身就是线程池线程。