.NET中的异步

.NET中4种异步方式?

1. ThreadPool.QueueUserworkItem实现
2. APM模式(就是BeginXXX和EndXXX成对出现。)
3. EAP模式(就是Event based, 准确说来就是任务在处理中或者处理完成，会抛出事件)
4. Task

Thead vs Task(4.0)
1.实例化一个Thread创建的是前台线程(可以通过修改Thread的IsBackground，将其变为后台线程)
2.Task启动的线程是后台线程，不过可以通过在Main方法中调用task.Wait()方法，使应用程序等待task执行完毕
3.Task与Thread的一个重要区分点是：Task底层是使用线程池的，而Thread每次实例化都会创建一个新的线程。

ASP.NET请求是如何处理的?

每个 ASP.NET 请求都要先通过 IIS，然后再由 ASP.NET 处理程序进行最终处理。 首先IIS 接收请求，初步处理后，发送给ASP.NET（必须是一个ASP.NET请求），然后由ASP.NET进行实际处理并生成响应，之后该响应通过IIS发回给客户。在IIS上，有一些工作进程负责从队列中取出请求，并执行IIS 模块，然后再将该请求发送到ASP.NET 队列。但是，ASP.NET本身不创建任何线程，也没有处理请求的线程池，而是通过使用CLR 线程池，从中获取线程来处理请求。因此，IIS 模块调用ThreadPool.QueueUserWorkItem，将请求排入队列，供CLR 工作线程处理。我们都知道，CLR线程池是由CLR管理，并且能够自动调整（也就是说，它根据需要创建和销毁进程）。这里还要记住，创建和销毁线程是项很繁重的任务，这就是为什么CLR线程池允许使用同一个线程处理多个任务。下面来看一个描述请求处理过程的图示。

在上图中可以看到，请求首先由 HTTP.sys接收，并添加到相应内核级应用程序池队列。然后，一个IIS工作线程从队列中取出请求，处理后将其传到ASP.NET 队列。注意，该请求如果不是一个ASP.NET请求，将从 IIS 自动返回。最后，从CLR线程池中分配一个线程，负责处理该请求。

ASP.NET中异步的使用场景是？

1. 基于线程池的请求处理

ASP.NET通过线程池的机制处理并发的HTTP请求。一个Web应用内部维护着一个线程池，当探测到抵达的针对本应用的请求时，会从池中获取一个空闲的线程来处理该请求。当处理完毕，线程不会被回收，而是重新释放到池中。线程池具有一个线程的最大容量，如果创建的线程达到这个上限并且所有的线程均被处于“忙碌”状态，新的HTTP请求会被放入一个请求队列以等待某个完成了请求处理任务的线程重新释放到池中。

我们将这些用于处理HTTP请求的线程称为工作线程（Worker Thread），而这个县城池自然就叫做工作线程池。ASP.NET这种基于线程池的请求处理机制主要具有如下两个优势：

• 工作线程的重用：创建线程的成本虽然不如进程的激活，却也不是一件“一蹴而就”的事情，频繁地创建和释放线程会对性能造成极大的损害。而线程池机制避免了总是创建新的工作线程来处理每一个请求，被创建的工作线程得到了极大地重用，并最终提高了服务器的吞吐能力。
• 工作线程数量的限制：资源的有限性具有了服务器处理请求的能力具有一个上限，或者说某台服务器能够处理的请求并发量具有一个临界点，一旦超过这个临界点，整台服务将会因不能提供足够的资源而崩溃。由于采用了对工作线程数量具有良好控制的线程池机制，ASP.NET MVC并发处理的请求数量不可能超过线程池的最大允许的容量，从而避免了在高并发情况下工作线程的无限制创建而最导致整个服务器的崩溃。

如果请求处理操作耗时较短，那么工作线程处理完毕后可以及时地被释放到线程池中以用于对下一个请求的处理。但是对于比较耗时的操作来说，意味着工作线程将被长时间被某个请求独占，如果这样的操作访问比较频繁，在高并发的情况下意味着线程池中将可能找不到空闲的工作线程用于及时处理最新抵达请求。

如果我们采用异步的方式来处理这样的耗时请求，工作线程可以让后台线程来接手，自己可以及时地被释放到线程池中用于进行后续请求的处理，从而提高了整个服务器的吞吐能力。值得一提的是，异步操作主要用于I/O绑定操作（比如数据库访问和远程服务调用等），而非CPU绑定操作，因为异步操作对整体性能的提升来源于：当I/O设备在处理某个任务的时候，CPU可以释放出来处理另一个任务。如果耗时操作主要依赖于本机CPU的运算，采用异步方法反而会因为线程调度和线程上下文的切换而影响整体的性能。

2.使用场景

所有请求大致可以分为两类：

1. CPU Bound 类 
2. I/O Bound 类

CPU Bound 类请求，需要 CPU 时间，而且是在同一进程中执行；而 I/O Bound 类请求，本身具有阻塞性，需要依赖其他模块执行 I/O 操作并返回响应。阻塞性请求是提高应用程序可伸缩性的主要障碍，而且大多数web应用程序中，在等待 I/O 操作的过程中浪费了大量时间。 因此以下场景适合使用异步：

1. I/O Bound 类请求，包括：

   a. 数据库访问

   b. 读/写文件

   c. Web 服务调用

   d. 访问网络资源

2. 事件驱动的请求，比如SignalR

3. 需要从多个数据源获取数据的场景