.NET中使用异步Async和Await的代价

最新推荐文章于 2024-09-05 15:15:57 发布

wangdingbang

最新推荐文章于 2024-09-05 15:15:57 发布

阅读量1.4k

点赞数

分类专栏： c# 文章标签： .net service function delegates closures generation

本文链接：https://blog.csdn.net/wangdingbang2013/article/details/7050695

版权

c# 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

看到了这样的一篇文章，觉得写的不错，与大家分享：

异步技术能使得应用程序的总吞吐量得到显著提升，但这并不是无偿的。异步函数往往比其同步替代方案稍慢一些，而且如果您不介意采用它还会增加相当大的内存压力的话。Stephen Toub最近在MSDN杂志中一篇题为“异步性能：了解Async和Await的代价”的文章中讨论了该主题。

相对于本机C++代码而言，托管代码最显著的优势之一就是运行时内联函数（inline function）^[1]的能力。CLR的JIT编译器甚至可以跨程序集内联函数，从而大大降低了调用细粒度方法（OOP程序员偏爱此类方法）的开销。不幸的是，异步调用的本质意味着不能内联委托（delegates cannot be inlined）。此外，在建立异步调用时还包括不少样板代码。因此，这导致了Stephen的第一条建议，“考虑粗粒度，而非细粒度（Think Chunky, Not Chatty）”^[2]。就像你正在穿越某个COM或p/invoke边界一样，相对于许多的小型异步调用而言，你应该会更喜爱少数的大型异步调用。

异步模式下无需开发者显式使用new运算符，即可通过多种方式分配内存。如果任其发展，这些内存分配法可能导致过大的内存压力，并且由于垃圾回收器尝试跟进还会导致不必要的延迟。考虑来自Stream子类的这个签名及其返回语句：

public override async Task<int> ReadAsync(…)
return this.Read(…)

此处没有展示隐式创建Task对象，该对象用于包装从Read方法中返回的整型值。在Stephen的文章中，他展示了如何通过缓存最近的Task<int>对象及重用该对象来降低内存开销。

导致意外对象分配和保留的另一原因是使用闭包（closures）。C#和VB中的闭包是通过匿名类来实现的，匿名类包含匿名方法，而且在方法中声明了异步函数。那些匿名函数所需的本地变量据说被“封闭”（closed over）或“提升” （lifted）到该匿名类中。当每次调用匿名类的父方法时都必须创建一个该类实例。

问题并未就此结束，仍有可能使得额外的内存分配进一步恶化。通常情况下，局部变量所引用的对象是被热切请求的，垃圾回收器（GC）一旦明确那些局部变量在当前函数中将不再被使用时就会回收它们。由于在异步函数中所使用的“局部变量”实际上是某个匿名类中的字段，因此在调用期间它们必须被保留。如果此过程耗时数秒，这对于异步调用而言是很常见的，而该匿名类可能在不经意间被晋升为垃圾回收器中更昂贵的1代或2代对象^[3]。如果这成为问题，Stephen建议一旦不再需要那些局部变量就应显式地把它们设置为空引用。

Stephen所讨论的第三个问题是上下文的概念，特别是同步上下文（synchronization context）和执行上下文（execution context）。他在文章中展示了库代码如何通过使用ConfigureAwait方法故意忽略同步上下文、以及避免某些必须在执行上下文中捕获的事情来获得性能提升的办法。

译注

[1] 内联函数（inline function），在不同的编程语言中，内联函数（inline function）是指已要求编辑器对其执行内联展开（inline expansion）的函数。换言之，程序员已要求编译器将每处调用某函数的地方都插入完整的函数体，而不是生成代码以便从其定义的地方调用该函数。可以使用C99或C++编写内联函数，例如：

inline int max(int a, int b)
{
  return (a > b) ? a : b;
}

然后，调用语句如下：

a = max(x, y);

该语句在编译后，可能被转换成为更直接的计算：

a = (x > y) ? x : y;

详见Inline function。

[2] 考虑粗粒度，而非细粒度（Think Chunky, Not Chatty），Chunky与Chatty之争此前多见于“服务协定设计”（service contract design）。唠叨的服务（Chatty Service）趋向于返回简化信息，并使用更细粒度的操作。矮胖的服务（Chunky Service）趋向于返回复杂层次信息，并使用粗粒度的操作。换言之，二者不同之处在于，当返回同样的信息时，唠叨的服务与矮胖的服务相比则需要更多的调用，却增加了返回实际需要的适当信息的灵活性。详见WCF service contract design。

[3] 1代或2代对象，“代”是垃圾回收器用到的概念。提到垃圾回收器就不得不说“托管堆的简化模型”，该模型的规则如下：