.net core解决线程池不足--为什么使用异步请求而不是使用更大的线程池？

这篇文章应该可以解释为什么使用异步，而不是同步的问题，以及同步下性能瓶颈出现时，怎么调整线程池以支持更大的并发。

问：

在荷兰的Techday期间，Steve Sanderson进行了有关异步Web的演讲。
他解释说，当请求需要很长时间才能完成时，线程池中的所有线程都变得繁忙，因此新的请求必须等待。服务器无法处理负载，一切都变慢了。
然后，他展示了异步Web请求的使用如何提高性能，因为随后将工作委派给另一个线程，并且线程池可以快速响应新的传入请求。他甚至对此进行了演示，并显示出50个并发请求首先花费了50 * 1s，但是异步行为总共只有1,2s。
但是看到这个之后，我仍然有一些疑问。

为什么我们不能只使用更大的线程池？是不是不是使用async / await来使另一个线程变慢，而是仅仅从一开始就增加了线程池？这不像我们运行的服务器突然获得更多线程之类的东西吗？
来自用户的请求仍在等待异步线程完成。如果池中的线程正在执行其他操作，那么“ UI”线程如何保持繁忙？史蒂夫（Steve）提到了一些“知道何时完成的智能内核”。这是如何运作的？

回答1：

这是一个非常好的问题ÿ