.NET中异步编程的原理是什么

这篇文章给大家介绍.NET中异步编程的原理是什么，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

为什么需要异步编程
       既然同步的写法更自然简单，异步的代码（传统的）不好写，还容易出错，那我们为什么需要去编写异步的代码呢？微软还要费这么大劲投入对Async CTP的开发呢？这其中肯定有一些原因。

快速响应的用户界面
       作为电脑的资深用户，我们肯定有多次“漏斗式鼠标”，“转圈式鼠标”的体验吧。点击一个按钮，然后鼠标就在那儿不停的转圈，再在界面上点两下，界面变灰，标题栏上出现“没有响应”。然后我们束手无策，性子好点的就在那儿等待一会儿，看看能不能恢复过来；性子不好的就打开任务管理器杀掉进程，杀掉进程容易，但有可能会破坏重要数据。

那造成这种情况到底是什么原因呢？概括成一句话就是：耗时的操作阻塞了UI线程，造成UI线程不能响应用户操作。关于更底层的原因请移步我的这篇文章:WinForm二三事（一）消息循环。那么这个时候我们就需要一种机制，在发起耗时操作的请求之后要立即返回，不要阻塞UI线程，让UI线程可以继续响应用用户的操作。然后等耗时操作返回后，通过回调来处理耗时操作返回的结果。下面是在UI上使用同步的方式和异步的方式的示意图：

更高的伸缩性
       对于服务器端应用来说，一般都是一个线程处理一个请求。另外一点是，线程的创建和销毁是昂贵的（这一点可以参考《CLR via C#》中Thread Baisc一章的描述），而服务器的资源肯定是有限的；并且，线程创建的越多，线程上下文切换就会变得越频繁。所以，为了创建高可伸缩性的服务，我们必须用最少的线程处理更多的请求，这样不仅能够做到消耗更少的资源（创建更少的线程），而且在应对请求突发增长的情况也很有用处，那么这里非常重要的一点就是不要阻塞线程，让线程池能够高效的工作。而且，在服务端应用中，有非常多的IO操作：数据库访问，磁盘操作，Socket访问等。对于这些IO操作，不属于计算密集型操作，是不需要单独分配一个线程来处理的。

要做到高可伸缩性，异步是一剂良药。假设现在这是一个web应用，当用户的HTTP request到来时，线程池提供一个线程来处理（忽略前面的排队等过程），然后到某一点，我们肯定需要读取磁盘、访问数据库，这个时候我们使用异步的方式，发起IO请求，然后处理HTTP request的线程就可以返回到线程池了，它可以继续处理其他请求，不需要在这里等待IO操作的返回。当IO操作完成之后，会通过回调（具体实现方式请参照后续文章）完成刚才那个HTTP reqeust后续的处理。

下面是使用同步方式和异步方式的示意图：

上图只画出了一个请求，高亮显示的那一段其实是不需要占用线程的，其实这段时间该线程可以返回线程池，然后分配去做其他请求，而数据库返回结果之后，再从线程池里分配一个线程来处理后续操作。这样，如果请求多的话，线程池就会创建更多的线程来处理请求，***结果大家应该都知道了。

从上图可以看出，开始的时候来自线程池的thread1处理请求，然后发起对数据库的请求，发起操作完毕后，thread1被线程池回收；当数据库将结果返回时线程池选择另外一个线程thread2（有可能是原来的那个线程，如果空闲的话）来处理数据库返回的结果，完成后续的操作。对于IO操作非常多的服务来说，所获得的益处是不可估量的。

关于.NET中异步编程的原理是什么就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。