异步编程最佳实践
Posted 程序源
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了异步编程最佳实践相关的知识，希望对你有一定的参考价值。
来源：tkb至简
链接：http://www.cnblogs.com/farb/p/4842920.html
避免async void
异步方法返回类型有3种，void，Task和Task<T>，void尽量不要使用。
原理剖析：
使用async void标记的方法有不同的错误处理语义。async Task或async Task方法抛出异常时，异常会被捕获并放到Task对象上。然而，标记为async void的方法没有Task对象，所以async void方法抛出的任何异常都会直接放到SynchronizationContext（异步上下文）上，它是在async void方法开始的时候激活的。下面是一个例子：
//async void 方法不能被捕获的异常
private async void ThrowExceptionAsync()
{
throw new InvalidOperationException();
}
public void AsyncVoidExceptions_CannotBeCaughtByCatch()
{
try
{
ThrowExceptionAsync();
}
catch (Exception )
{
//异常不会被捕获
throw;
}
}
async void有不同的组成语法。返回Task或Task的async方法可以使用await Task.WhenAny或Task.WhenAll等轻易组合。而返回void的async方法没有提供简单的方式来通知它们已经完成的调用代码。启用若干个async void方法很容易，但不容易决定它们什么时候完成。async void方法开始和完成时会通知它们的SynchronizationContext，但是自定义的SynchronizationContext对于常规应用代码是一个复杂的解决方案。
async void方法测试很困难。由于错误处理和组合的差异，编写调用async void方法的单元测试很困难。
很明显，async void方法与async Task方法相比有很多劣势，但在一个特殊场合很有用，那就是异步的事件句柄。它们直接将异常抛出到SynchronizationContext，这与同步的事件句柄表现很相似。同步的事件句柄通常是私有的，因此它们不能被组合或者直接测试。我想采取的方法是在异步事件句柄中最小化代码，比如，让它await一个包含实际逻辑的async Task方法，代码如下：
private async void button1_Click(object sender, EventArgs e)
{
await Button1ClickAsync();
}
public async Task Button1ClickAsync()
{
//处理异步工作
await Task.Delay(1000);
}
总之，对于async Task和async void,你应该更喜欢前者。async Task方法更容易错误处理，组合和测试。对于异步的事件句柄异常，必须返回void。
一直使用async
这句话的意思是，不要不经过认真考虑就混合同步和异步代码。特别地，在异步代码上使用Task.Wait或Task.Result是一个馊主意。
下面是一个简单的例子：一个方法阻塞了异步方法的结果。在控制台程序中会工作的很好，但是从GUI或者ASP.Net上下文中调用的时候就会死锁。死锁的实际原因是当调用Task.Wait的时候进一步开启了调用栈。
//阻塞异步代码时的一个常见死锁问题
public static class DeadlockDemo
{
private static async Task DelayAsync()
{
await Task.Delay(1000);
}
// 调用 GUI 或 ASP.NET 上下文的时候会造成死锁
public static void Test()
{
// 开始延迟.
var delayTask = DelayAsync();
// 等待延迟
delayTask.Wait();
}
}
造成这种死锁的根本原因是等待处理上下文的方式。默认情况下，当一个未完成的Task处于被等待状态时，当前上下文会被捕获并且当此任务完成时恢复该方法。这个上下文如果不为null就是当前的SynchronizationContext，在这种情况下，它是当前的TaskScheduler（任务调度者）。GUI 和ASP.NET应用有一个SynchronizationContext，它只允许一次运行一大块代码。当await完成时，它尝试在捕获的上下文内执行异步方法的剩余部分。但是该上下文已经有一个线程了，它在（同步地）等待这个async方法的完成。它们每一个都在等待另一个，造成了死锁。
注意控制台程序不会造成这种死锁。它们有个线程池SynchronizationContext而没有一次执行一大坨代码的SynchronizationContext，因此当await完成时，它在线程池线程上调度该async方法的剩余部分。该方法可以完成，它完成了返回task，并没有死锁。
总之，应该避免混合async和阻塞的代码。这样做的话会造成死锁，更复杂的错误处理和上下文线程不可预测的阻塞。
配置上下文
这里稍加补充如下：
除了性能方面之外，ConfigureAwait还有另一个重要的方面：它可以避免死锁。在“一直使用async”的代码示例中，再次思考一下：如果你在DelayAsync代码行添加“ConfigureAwait(false)”，那么死锁就会避免。这次，当await完成时，它尝试在线程池上下文内执行async方法的剩余部分。该方法可以完成，完成后返回task,并且没有死锁。这项技术对于逐渐将应用从同步转为异步特别有用。
建议将ConfigureAwait用在方法中的每个await之后。只有当未完成的Task被等待时，才会唤起上下文被捕获；如果Task已经完成了，那么上下文不会被捕获。
async Task MyMethodAsync()
{
//这里的代码运行在原始 context.
await Task.FromResult(1);
//这里的代码运行在原始 context.
await Task.FromResult(1).ConfigureAwait(continueOnCapturedContext: false);
// 这里的代码运行在原始 context.
var random = new Random();
int delay = random.Next(2); // delay是 0 or 1
await Task.Delay(delay).ConfigureAwait(continueOnCapturedContext: false);
// 这里的代码不确定是否运行在原始 context.
}
每个异步方法都有自己的上下文，因此如果一个异步方法调用另一个异步方法，那么它们的上下文是独立的。
private async Task HandleClickAsync()
{
// 这里可以使用ConfigureAwait
await Task.Delay(1000).ConfigureAwait(continueOnCapturedContext: false);
}
private async void button1_Click(object sender, EventArgs e)
{
button1.Enabled = false;
try
{
// 这里不能使用 ConfigureAwait
await HandleClickAsync();
}
finally
{
// 返回到这个方法的原始上下文
button1.Enabled = true;
}
}
近期热文
进入程序源专属微信群，早报早知道。
请添加小编微信：szweican(备注岗位)
以上是关于异步编程最佳实践的主要内容，如果未能解决你的问题，请参考以下文章