使用Async和Await的代价

作者 Jonathan Allen 译者 高翌翔 发布于 2011年10月13日

领域

语言 & 开发

主题

C# ,

Visual Basic.NET ,

.NET ,

编程

分享到

异步技术能使得应用程序的总吞吐量得到显著提升，但这并不是无偿的。异步函数往往比其同步替代方案稍慢一些，而且如果您不介意采用它还会增加相当大的内存压力的话。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代对象，“代”是垃圾回收器用到的概念。提到垃圾回收器就不得不说“托管堆的简化模型”，该模型的规则如下：

• 所有可进行垃圾回收的对象都分配在一个连续的地址空间范围（托管堆）内。
• 堆被划分为代 (generation)，以便只需查找堆的一小部分就能清除大多数垃圾。
• 代中的对象大体上均为同龄。
• 代的编号越高，表示堆的这一片区域所包含的对象越老——这些对象就越有可能是稳定的。最老的对象位于最低的地址内，而新的对象则创建在增加的地址内。
• 新对象的分配指针标记了内存的已使用（已分配）内存区域和未使用（可用）内存区域之间的边界。
• 通过删除死对象并将活对象转移到堆的低地址末尾，堆周期性地进行压缩。这就扩展了在创建新对象的图表底部的未使用区域。
• 对象在内存中的顺序仍然是创建它们的顺序，以便于定位。
• 在堆中，对象之间永远不会有任何空隙。
• 只有某些可用空间是已提交的。需要时，操作系统会从“保留的”地址范围中分配更多的内存。

详见“垃圾回收器基础与性能提示”。

查看英文原文：The Cost of Async and Await

译者 高翌翔 基于.NET平台进行Web应用程序设计、开发，关注敏捷开发和架构设计，及各种提高代码可维护性的最佳实践。