在《Pro ASP.NET MVC 4》一书中,有一个异步操作的示例:
我的问题是:任务不仅使用线程池中用于处理请求的线程吗?
假设我有一个同步I/O绑定方法。我认为在我的操作中使用Task.Run并等待调用此方法不会导致可以同时处理的更多请求,因为I/O绑定方法的任务不再可用于请求处理。或者是否只有用于请求的单独线程池,并且在操作中使用Task.Run自动使用不同的线程池?这个问题让我思考:在高流量场景下在ASP.NET中使用ThreadPool.QueueUserWorkItem,其中答案或多或少是应仅使用来自库的异步方法,这些库使用其自己的线程池。
是否可以配置该行为?在ASP.NET WebForms中是否起作用相同?
public class RemoteDataController : AsyncController
{
public async Task<ActionResult> ConsumeAsyncMethod() {
string data = await new RemoteService().GetRemoteDataAsync();
return View("Data", (object)data);
}
}
public class RemoteService
{
public async Task<string> GetRemoteDataAsync() {
return await Task<string>.Factory.StartNew(() => {
Thread.Sleep(2000);
return "Hello from the other side of the world";
});
}
}
我的问题是:任务不仅使用线程池中用于处理请求的线程吗?
假设我有一个同步I/O绑定方法。我认为在我的操作中使用Task.Run并等待调用此方法不会导致可以同时处理的更多请求,因为I/O绑定方法的任务不再可用于请求处理。或者是否只有用于请求的单独线程池,并且在操作中使用Task.Run自动使用不同的线程池?这个问题让我思考:在高流量场景下在ASP.NET中使用ThreadPool.QueueUserWorkItem,其中答案或多或少是应仅使用来自库的异步方法,这些库使用其自己的线程池。
是否可以配置该行为?在ASP.NET WebForms中是否起作用相同?
Task.Delay
永远不需要线程,但还有其他可能需要的东西。然而,从Web应用程序的角度来看,是“无线程”的工作,因此并没有错,只是不完全准确。 - Chris PrattTask.Delay
:BCL实际上有一个“计时器线程”,负责所有托管计时器,因此计时器有一个BCL线程。 但这只是AppDomain中的一个线程,而不是每个计时器。 这里的原则相同:我们避免了每个请求都需要额外线程的情况。 - Stephen Cleary