c# 异步的理解
第一部分：阅读目录
转自：http://www.cnblogs.com/zhaopei/p/async_one.html
新进阶的程序员可能对async、await用得比较多，却对之前的异步了解甚少。本人就是此类，因此打算回顾学习下异步的进化史。
本文主要是回顾async异步模式之前的异步，下篇文章再来重点分析async异步模式。
APM
APM 异步编程模型，Asynchronous Programming Model
早在C#1的时候就有了APM。虽然不是很熟悉，但是多少还是见过的。就是那些类是BeginXXX和EndXXX的方法，且BeginXXX返回值是IAsyncResult接口。
在正式写APM示例之前我们先给出一段同步代码：
//1、同步方法
private void button1_Click(object sender, EventArgs e)
{
Debug.WriteLine("【Debug】线程ID:" + Thread.CurrentThread.ManagedThreadId);
var request = WebRequest.Create("https://github.com/");//为了更好的演示效果，我们使用网速比较慢的外网
request.GetResponse();//发送请求
Debug.WriteLine("【Debug】线程ID:" + Thread.CurrentThread.ManagedThreadId);
label1.Text = "执行完毕！";
}
【说明】为了更好的演示异步效果，这里我们使用winform程序来做示例。（因为winform始终都需要UI线程渲染界面，如果被UI线程占用则会出现“假死”状态）
【效果图】
看图得知：
- 我们在执行方法的时候页面出现了“假死”，拖不动了。
- 我们看到打印结果，方法调用前和调用后线程ID都是9（也就是同一个线程）
下面我们再来演示对应的异步方法：（BeginGetResponse、EndGetResponse所谓的APM异步模型）
private void button2_Click(object sender, EventArgs e)
{
//1、APM 异步编程模型，Asynchronous Programming Model
//C#1[基于IAsyncResult接口实现BeginXXX和EndXXX的方法]
Debug.WriteLine("【Debug】主线程ID:" + Thread.CurrentThread.ManagedThreadId);
var request = WebRequest.Create("https://github.com/");
request.BeginGetResponse(new AsyncCallback(t =>//执行完成后的回调
{
var response = request.EndGetResponse(t);
var stream = response.GetResponseStream();//获取返回数据流
using (StreamReader reader = new StreamReader(stream))
{
StringBuilder sb = new StringBuilder();
while (!reader.EndOfStream)
{
var content = reader.ReadLine();
sb.Append(content);
}
Debug.WriteLine("【Debug】" + sb.ToString().Trim().Substring(0, 100) + "...");//只取返回内容的前100个字符
Debug.WriteLine("【Debug】异步线程ID:" + Thread.CurrentThread.ManagedThreadId);
label1.Invoke((Action)(() => { label1.Text = "执行完毕！"; }));//这里跨线程访问UI需要做处理
}
}), null);
Debug.WriteLine("【Debug】主线程ID:" + Thread.CurrentThread.ManagedThreadId);
}
【效果图】
看图得知：
- 启用异步方法并没有是UI界面卡死
- 异步方法启动了另外一个ID为12的线程
上面代码执行顺序：
前面我们说过，APM的BebinXXX必须返回IAsyncResult接口。那么接下来我们分析IAsyncResult接口：
首先我们看：
确实返回的是IAsyncResult接口。那IAsyncResult到底长的什么样子？：
并没有想象中的那么复杂嘛。我们是否可以尝试这实现这个接口，然后显示自己的异步方法呢？
首先定一个类MyWebRequest，然后继承IAsyncResult：（下面是基本的伪代码实现）
public class MyWebRequest : IAsyncResult
{
public object AsyncState
{
get { throw new NotImplementedException(); }
}
public WaitHandle AsyncWaitHandle
{
get { throw new NotImplementedException(); }
}
public bool CompletedSynchronously
{
get { throw new NotImplementedException(); }
}
public bool IsCompleted
{
get { throw new NotImplementedException(); }
}
}
这样肯定是不能用的，起码也得有个存回调函数的属性吧，下面我们稍微改造下：
然后我们可以自定义APM异步模型了：（成对的Begin、End）
public IAsyncResult MyBeginXX(AsyncCallback callback)
{
var asyncResult = new MyWebRequest(callback, null);
var request = WebRequest.Create("https://github.com/");
new Thread(() => //重新启用一个线程
{
using (StreamReader sr = new StreamReader(request.GetResponse().GetResponseStream()))
{
var str = sr.ReadToEnd();
asyncResult.SetComplete(str);//设置异步结果
}
}).Start();
return asyncResult;//返回一个IAsyncResult
}
public string MyEndXX(IAsyncResult asyncResult)
{
MyWebRequest result = asyncResult as MyWebRequest;
return result.Result;
}
调用如下:
private void button4_Click(object sender, EventArgs e)
{
Debug.WriteLine("【Debug】主线程ID:" + Thread.CurrentThread.ManagedThreadId);
MyBeginXX(new AsyncCallback(t =>
{
var result = MyEndXX(t);
Debug.WriteLine("【Debug】" + result.Trim().Substring(0, 100) + "...");
Debug.WriteLine("【Debug】异步线程ID:" + Thread.CurrentThread.ManagedThreadId);
}));
Debug.WriteLine("【Debug】主线程ID:" + Thread.CurrentThread.ManagedThreadId);
}
效果图：
我们看到自己实现的效果基本上和系统提供的差不多。
- 启用异步方法并没有是UI界面卡死
- 异步方法启动了另外一个ID为11的线程
【总结】
个人觉得APM异步模式就是启用另外一个线程执行耗时任务，然后通过回调函数执行后续操作。
APM还可以通过其他方式获取值，如：
while (!asyncResult.IsCompleted)//循环，直到异步执行完成 (轮询方式)
{
Thread.Sleep(100);
}
var stream2 = request.EndGetResponse(asyncResult).GetResponseStream();
或
asyncResult.AsyncWaitHandle.WaitOne();//阻止线程，直到异步完成 （阻塞等待） var stream2 = request.EndGetResponse(asyncResult).GetResponseStream();
补充：如果是普通方法，我们也可以通过委托异步：（BeginInvoke、EndInvoke）
public void MyAction()
{
var func = new Func<string, string>(t =>
{
Thread.Sleep(2000);
return "name:" + t + DateTime.Now.ToString();
});
var asyncResult = func.BeginInvoke("张三", t =>
{
string str = func.EndInvoke(t);
Debug.WriteLine(str);
}, null);
}
EAP
EAP 基于事件的异步模式，Event-based Asynchronous Pattern
此模式在C#2的时候随之而来。
先来看个EAP的例子：
private void button3_Click(object sender, EventArgs e)
{
Debug.WriteLine("【Debug】主线程ID:" + Thread.CurrentThread.ManagedThreadId);
BackgroundWorker worker = new BackgroundWorker();
worker.DoWork += new DoWorkEventHandler((s1, s2) =>
{
Thread.Sleep(2000);
Debug.WriteLine("【Debug】异步线程ID:" + Thread.CurrentThread.ManagedThreadId);
});//注册事件来实现异步
worker.RunWorkerAsync(this);
Debug.WriteLine("【Debug】主线程ID:" + Thread.CurrentThread.ManagedThreadId);
}
【效果图】（同样不会阻塞UI界面）
【特征】
- 通过事件的方式注册回调函数
- 通过 XXXAsync方法来执行异步调用
例子很简单，但是和APM模式相比，是不是没有那么清晰透明。为什么可以这样实现？事件的注册是在干嘛？为什么执行RunWorkerAsync会触发注册的函数？
感觉自己又想多了...
我们试着反编译看看源码：
只想说，这么玩，有意思吗？
TAP
TAP 基于任务的异步模式，Task-based Asynchronous Pattern
到目前为止，我们觉得上面的APM、EAP异步模式好用吗？好像没有发现什么问题。再仔细想想...如果我们有多个异步方法需要按先后顺序执行，并且需要(在主进程)得到所有返回值。
首先定义三个委托：
public Func<string, string> func1()
{
return new Func<string, string>(t =>
{
Thread.Sleep(2000);
return "name:" + t;
});
}
public Func<string, string> func2()
{
return new Func<string, string>(t =>
{
Thread.Sleep(2000);
return "age:" + t;
});
}
public Func<string, string> func3()
{
return new Func<string, string>(t =>
{
Thread.Sleep(2000);
return "sex:" + t;
});
}
然后按照一定顺序执行：
public void MyAction()
{
string str1 = string.Empty, str2 = string.Empty, str3 = string.Empty;
IAsyncResult asyncResult1 = null, asyncResult2 = null, asyncResult3 = null;
asyncResult1 = func1().BeginInvoke("张三", t =>
{
str1 = func1().EndInvoke(t);
Debug.WriteLine("【Debug】异步线程ID:" + Thread.CurrentThread.ManagedThreadId);
asyncResult2 = func2().BeginInvoke("26", a =>
{
str2 = func2().EndInvoke(a);
Debug.WriteLine("【Debug】异步线程ID:" + Thread.CurrentThread.ManagedThreadId);
asyncResult3 = func3().BeginInvoke("男", s =>
{
str3 = func3().EndInvoke(s);
Debug.WriteLine("【Debug】异步线程ID:" + Thread.CurrentThread.ManagedThreadId);
}, null);
}, null);
}, null);
asyncResult1.AsyncWaitHandle.WaitOne();
asyncResult2.AsyncWaitHandle.WaitOne();
asyncResult3.AsyncWaitHandle.WaitOne();
Debug.WriteLine(str1 + str2 + str3);
}
除了难看、难读一点好像也没什么 。不过真的是这样吗？
asyncResult2是null?
由此可见在完成第一个异步操作之前没有对asyncResult2进行赋值，asyncResult2执行异步等待的时候报异常。那么如此我们就无法控制三个异步函数，按照一定顺序执行完成后再拿到返回值。（理论上还是有其他办法的，只是会然代码更加复杂）
是的，现在该我们的TAP登场了。
只需要调用Task类的静态方法Run，即可轻轻松松使用异步。
获取返回值：
var task1 = Task<string>.Run(() =>
{
Thread.Sleep(1500);
Console.WriteLine("【Debug】task1 线程ID:" + Thread.CurrentThread.ManagedThreadId);
return "张三";
});
//其他逻辑
task1.Wait();
var value = task1.Result;//获取返回值
Console.WriteLine("【Debug】主 线程ID:" + Thread.CurrentThread.ManagedThreadId);
现在我们处理上面多个异步按序执行：
Console.WriteLine("【Debug】主 线程ID:" + Thread.CurrentThread.ManagedThreadId);
string str1 = string.Empty, str2 = string.Empty, str3 = string.Empty;
var task1 = Task.Run(() =>
{
Thread.Sleep(500);
str1 = "姓名：张三,";
Console.WriteLine("【Debug】task1 线程ID:" + Thread.CurrentThread.ManagedThreadId);
}).ContinueWith(t =>
{
Thread.Sleep(500);
str2 = "年龄：25,";
Console.WriteLine("【Debug】task2 线程ID:" + Thread.CurrentThread.ManagedThreadId);
}).ContinueWith(t =>
{
Thread.Sleep(500);
str3 = "爱好：妹子";
Console.WriteLine("【Debug】task3 线程ID:" + Thread.CurrentThread.ManagedThreadId);
});
Thread.Sleep(2500);//其他逻辑代码
task1.Wait();
Debug.WriteLine(str1 + str2 + str3);
Console.WriteLine("【Debug】主 线程ID:" + Thread.CurrentThread.ManagedThreadId);
[效果图]
我们看到，结果都得到了，且是异步按序执行的。且代码的逻辑思路非常清晰。如果你感受还不是很大，那么你现象如果是100个异步方法需要异步按序执行呢？用APM的异步回调，那至少也得异步回调嵌套100次。那代码的复杂度可想而知。
延伸思考
-
WaitOne完成等待的原理
-
异步为什么会提升性能
-
线程的使用数量和CPU的使用率有必然的联系吗
问题1：WaitOne完成等待的原理
在此之前，我们先来简单的了解下多线程信号控制AutoResetEvent类。
var _asyncWaitHandle = new AutoResetEvent(false); _asyncWaitHandle.WaitOne();
此代码会在 WaitOne 的地方会一直等待下去。除非有另外一个线程执行 AutoResetEvent 的set方法。
var _asyncWaitHandle = new AutoResetEvent(false); _asyncWaitHandle.Set(); _asyncWaitHandle.WaitOne();
如此，到了 WaitOne 就可以直接执行下去。没有有任何等待。
现在我们对APM 异步编程模型中的 WaitOne 等待是不是知道了点什么呢。我们回头来实现之前自定义异步方法的异步等待。
public class MyWebRequest : IAsyncResult
{
//异步回调函数（委托）
private AsyncCallback _asyncCallback;
private AutoResetEvent _asyncWaitHandle;
public MyWebRequest(AsyncCallback asyncCallback, object state)
{
_asyncCallback = asyncCallback;
_asyncWaitHandle = new AutoResetEvent(false);
}
//设置结果
public void SetComplete(string result)
{
Result = result;
IsCompleted = true;
_asyncWaitHandle.Set();
if (_asyncCallback != null)
{
_asyncCallback(this);
}
}
//异步请求返回值
public string Result { get; set; }
//获取用户定义的对象，它限定或包含关于异步操作的信息。
public object AsyncState
{
get { throw new NotImplementedException(); }
}
// 获取用于等待异步操作完成的 System.Threading.WaitHandle。
public WaitHandle AsyncWaitHandle
{
//get { throw new NotImplementedException(); }
get { return _asyncWaitHandle; }
}
//获取一个值，该值指示异步操作是否同步完成。
public bool CompletedSynchronously
{
get { throw new NotImplementedException(); }
}
//获取一个值，该值指示异步操作是否已完成。
public bool IsCompleted
{
get;
private set;
}
}
红色代码就是新增的异步等待。
【执行步骤】
问题2：异步为什么会提升性能
比如同步代码：
Thread.Sleep(10000);//假设这是个访问数据库的方法 Thread.Sleep(10000);//假设这是个访问FQ网站的方法
这个代码需要20秒。
如果是异步：
var task = Task.Run(() =>
{
Thread.Sleep(10000);//假设这是个访问数据库的方法
});
Thread.Sleep(10000);//假设这是个访问FQ网站的方法
task.Wait();
如此就只要10秒了。这样就节约了10秒。
如果是：
var task = Task.Run(() =>
{
Thread.Sleep(10000);//假设这是个访问数据库的方法
});
task.Wait();
异步执行中间没有耗时的代码那么这样的异步将是没有意思的。
或者：
var task = Task.Run(() =>
{
Thread.Sleep(10000);//假设这是个访问数据库的方法
});
task.Wait();
Thread.Sleep(10000);//假设这是个访问FQ网站的方法
把耗时任务放在异步等待后，那这样的代码也是不会有性能提升的。
还有一种情况：
如果是单核CPU进行高密集运算操作，那么异步也是没有意义的。(因为运算是非常耗CPU,而网络请求等待不耗CPU)
问题3：线程的使用数量和CPU的使用率有必然的联系吗
答案是否。
还是拿单核做假设。
情况1：
long num = 0;
while (true)
{
num += new Random().Next(-100,100);
//Thread.Sleep(100);
}
单核下，我们只启动一个线程，就可以让你CPU爆满。
启动八次，八进程CPU基本爆满。
情况2：
一千多个线程，而CPU的使用率竟然是0。由此，我们得到了之前的结论，线程的使用数量和CPU的使用率没有必然的联系。
虽然如此，但是也不能毫无节制的开启线程。因为：
- 开启一个新的线程的过程是比较耗资源的。（可是使用线程池，来降低开启新线程所消耗的资源）
- 多线程的切换也是需要时间的。
- 每个线程占用了一定的内存保存线程上下文信息。
第二部分：阅读目录
转自：http://www.cnblogs.com/zhaopei/p/async_two.html
接上篇：《C#异步的世界【上】》
上篇主要分析了async\await之前的一些异步模式，今天说异步的主要是指C#5的async\await异步。在此为了方便的表述，我们称async\await之前的异步为“旧异步”，async\await为“新异步”。
新异步的使用
只能说新异步的使用太简单（如果仅仅只是说使用）
方法加上async修饰符，然后使用await关键字执行异步方法，即可。对就是如此简单。像使用同步方法逻辑一样使用异步。
public async Task<int> Test()
{
var num1 = await GetNumber(1);
var num2 = await GetNumber(num1);
var task = GetNumber(num2);
//或者
var num3 = await task;
return num1 + num2 + num3;
}
新异步的优势
在此之前已经有了多种异步模式，为什么还要引入和学习新的async\await异步呢？当然它肯定是有其独特的优势。
我们分两个方面来分析：WinForm、WPF等单线程UI程序和Web后台服务程序。
对于WinForm、WPF等单线程UI程序
代码1（旧异步）
private void button1_Click(object sender, EventArgs e)
{
var request = WebRequest.Create("https://github.com/");
request.BeginGetResponse(new AsyncCallback(t =>
{
//（1）处理请求结果的逻辑必须写这里
label1.Invoke((Action)(() => { label1.Text = "[旧异步]执行完毕！"; }));//（2）这里跨线程访问UI需要做处理
}), null);
}
代码2（同步）
private void button3_Click(object sender, EventArgs e)
{
HttpClient http = new HttpClient();
var htmlStr = http.GetStringAsync("https://github.com/").Result;
//（1）处理请求结果的逻辑可以写这里
label1.Text = "[同步]执行完毕！";//（2）不在需要做跨线程UI处理了
}
代码3（新异步）
private async void button2_Click(object sender, EventArgs e)
{
HttpClient http = new HttpClient();
var htmlStr = await http.GetStringAsync("https://github.com/");
//（1）处理请求结果的逻辑可以写这里
label1.Text = "[新异步]执行完毕！";//（2）不在需要做跨线程UI处理了
}
新异步的优势：
- 没有了烦人的回调处理
- 不会像同步代码一样阻塞UI界面（造成假死）
- 不在像旧异步处理后访问UI不在需要做跨线程处理
- 像使用同步代码一样使用异步（超清晰的逻辑）
是的，说得再多还不如看看实际效果图来得实际：（新旧异步UI线程没有阻塞，同步阻塞了UI线程）
【思考】：旧的异步模式是开启了一个新的线程去执行，不会阻塞UI线程。这点很好理解。可是，新的异步看上去和同步区别不大，为什么也不会阻塞界面呢？
【原因】：新异步，在执行await表达式前都是使用UI线程，await表达式后会启用新的线程去执行异步，直到异步执行完成并返回结果，然后再回到UI线程（据说使用了SynchronizationContext）。所以，await是没有阻塞UI线程的，也就不会造成界面的假死。
【注意】：我们在演示同步代码的时候使用了Result。然，在UI单线程程序中使用Result来使异步代码当同步代码使用是一件很危险的事（起码对于不太了解新异步的同学来说是这样）。至于具体原因稍候再分析（哎呀，别跑啊）。
对于Web后台服务程序
也许对于后台程序的影响没有单线程程序那么直观，但其价值也是非常大的。且很多人对新异步存在误解。
【误解】：新异步可以提升Web程序的性能。
【正解】：异步不会提升单次请求结果的时间，但是可以提高Web程序的吞吐量。
1、为什么不会提升单次请求结果的时间？
其实我们从上面示例代码（虽然是UI程序的代码）也可以看出。
2、为什么可以提高Web程序的吞吐量？
那什么是吞吐量呢，也就是本来只能十个人同时访问的网站现在可以二十个人同时访问了。也就是常说的并发量。
还是用上面的代码来解释。[代码2] 阻塞了UI线程等待请求结果，所以UI线程被占用，而[代码3]使用了新的线程请求，所以UI线程没有被占用，而可以继续响应UI界面。
那问题来了，我们的Web程序天生就是多线程的，且web线程都是跑的线程池线程（使用线程池线程是为了避免不断创建、销毁线程所造成的资源成本浪费）,而线程池线程可使用线程数量是一定的，尽管可以设置，但它还是会在一定范围内。如此一来，我们web线程是珍贵的（物以稀为贵），不能滥用。用完了，那么其他用户请求的时候就无法处理直接503了。
那什么算是滥用呢？比如：文件读取、URL请求、数据库访问等IO请求。如果用web线程来做这个耗时的IO操作那么就会阻塞web线程，而web线程阻塞得多了web线程池线程就不够用了。也就达到了web程序最大访问数。
此时我们的新异步横空出世，解放了那些原本处理IO请求而阻塞的web线程（想偷懒？没门，干活了。）。通过异步方式使用相对廉价的线程（非web线程池线程）来处理IO操作，这样web线程池线程就可以解放出来处理更多的请求了。
不信？下面我们来测试下：
【测试步骤】:
1、新建一个web api项目
2、新建一个数据访问类，分别提供同步、异步方法(在方法逻辑执行前后读取时间、线程id、web线程池线程使用数)
public class GetDataHelper
{
/// <summary>
/// 同步方法获取数据
/// </summary>
/// <returns></returns>
public string GetData()
{
var beginInfo = GetBeginThreadInfo();
using (HttpClient http = new HttpClient())
{
http.GetStringAsync("https://github.com/").Wait();//注意：这里是同步阻塞
}
return beginInfo + GetEndThreadInfo();
}
/// <summary>
/// 异步方法获取数据
/// </summary>
/// <returns></returns>
public async Task<string> GetDataAsync()
{
var beginInfo = GetBeginThreadInfo();
using (HttpClient http = new HttpClient())
{
await http.GetStringAsync("https://github.com/");//注意：这里是异步等待
}
return beginInfo + GetEndThreadInfo();
}
public string GetBeginThreadInfo()
{
int t1, t2, t3;
ThreadPool.GetAvailableThreads(out t1, out t3);
ThreadPool.GetMaxThreads(out t2, out t3);
return string.Format("开始:{0:mm:ss,ffff} 线程Id:{1} Web线程数:{2}",
DateTime.Now,
Thread.CurrentThread.ManagedThreadId,
t2 - t1);
}
public string GetEndThreadInfo()
{
int t1, t2, t3;
ThreadPool.GetAvailableThreads(out t1, out t3);
ThreadPool.GetMaxThreads(out t2, out t3);
return string.Format(" 结束:{0:mm:ss,ffff} 线程Id:{1} Web线程数:{2}",
DateTime.Now,
Thread.CurrentThread.ManagedThreadId,
t2 - t1);
}
}
3、新建一个web api控制器
[HttpGet]
public async Task<string> Get(string str)
{
GetDataHelper sqlHelper = new GetDataHelper();
switch (str)
{
case "异步处理"://
return await sqlHelper.GetDataAsync();
case "同步处理"://
return sqlHelper.GetData();
}
return "参数不正确";
}
4、发布web api程序，部署到本地iis(同步链接：http://localhost:803/api/Home?str=同步处理 异步链接：http://localhost:803/api/Home?str=异步处理)
5、接着上面的winform程序里面测试请求：(同时发起10个请求)
private void button6_Click(object sender, EventArgs e)
{
textBox1.Text = "";
label1.Text = "";
Task.Run(() =>
{
TestResultUrl("http://localhost:803/api/Home?str=同步处理");
});
}
private void button5_Click(object sender, EventArgs e)
{
textBox1.Text = "";
label1.Text = "";
Task.Run(() =>
{
TestResultUrl("http://localhost:803/api/Home?str=异步处理");
});
}
public void TestResultUrl(string url)
{
int resultEnd = 0;
HttpClient http = new HttpClient();
int number = 10;
for (int i = 0; i < number; i++)
{
new Thread(async () =>
{
var resultStr = await http.GetStringAsync(url);
label1.Invoke((Action)(() =>
{
textBox1.AppendText(resultStr.Replace(" ", "\r\t") + "\r\n");
if (++resultEnd >= number)
{
label1.Text = "全部执行完毕";
}
}));
}).Start();
}
}
6、重启iis，并用浏览器访问一次要请求的链接地址（预热）
7、启动winform程序，点击“访问同步实现的Web”：
8、重复6，然后重新启动winform程序点击“访问异步实现的Web”
看到这些数据有什么感想？
数据和我们前面的【正解】完全吻合。仔细观察，每个单次请求用时基本上相差不大。 但是步骤7"同步实现"最高投入web线程数是10,而步骤8“异步实现”最高投入web线程数是3。
也就是说“异步实现”使用更少的web线程完成了同样的请求数量，如此一来我们就有更多剩余的web线程去处理更多用户发起的请求。
接着我们还发现同步实现请求前后的线程ID是一致的，而异步实现前后线程ID不一定一致。再次证明执行await异步前释放了主线程。
【结论】：
- 使用新异步可以提升Web服务程序的吞吐量
- 对于客户端来说，web服务的异步并不会提高客户端的单次访问速度。
- 执行新异步前会释放web线程，而等待异步执行完成后又回到了web线程上。从而提高web线程的利用率。
【图解】：
Result的死锁陷阱
我们在分析UI单线程程序的时候说过，要慎用异步的Result属性。下面我们来分析：
private void button4_Click(object sender, EventArgs e)
{
label1.Text = GetUlrString("https://github.com/").Result;
}
public async Task<string> GetUlrString(string url)
{
using (HttpClient http = new HttpClient())
{
return await http.GetStringAsync(url);
}
}
代码 GetUlrString("https://github.com/").Result 的Result属性会阻塞(占用)UI线程，而执行到GetUlrString方法的 await异步的时候又要释放UI线程。此时矛盾就来了，由于线程资源的抢占导致死锁。
且Result属性和.Wait()方法一样会阻塞线程。此等问题在Web服务程序里面一样存在。（区别：UI单次线程程序和web服务程序都会释放主线程，不同的是Web服务线程不一定会回到原来的主线程，而UI程序一定会回到原来的UI线程）
我们前面说过，.net为什么会这么智能的自动释放主线程然后等待异步执行完毕后又回到主线程是因为SynchronizationContext的功劳。
但这里有个例外，那就是控制台程序里面是没有SynchronizationContext的。所以这段代码放在控制台里面运行是没有问题的。
static void Main(string[] args)
{
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
GetUlrString("https://github.com/").Wait();
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
Console.ReadKey();
}
public async static Task<string> GetUlrString(string url)
{
using (HttpClient http = new HttpClient())
{
Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
return await http.GetStringAsync(url);
}
}
打印出来的都是同一个线程ID
使用AsyncHelper在同步代码里面调用异步
但可是，可但是，我们必须在同步方法里面执行异步怎办？办法肯定是有的
我们首先定义一个AsyncHelper静态类：
static class AsyncHelper
{
private static readonly TaskFactory _myTaskFactory = new TaskFactory(CancellationToken.None,
TaskCreationOptions.None, TaskContinuationOptions.None, TaskScheduler.Default);
public static TResult RunSync<TResult>(Func<Task<TResult>> func)
{
return _myTaskFactory.StartNew(func).Unwrap().GetAwaiter().GetResult();
}
public static void RunSync(Func<Task> func)
{
_myTaskFactory.StartNew(func).Unwrap().GetAwaiter().GetResult();
}
}
然后调用异步：
private void button7_Click(object sender, EventArgs e)
{
label1.Text = AsyncHelper.RunSync(() => GetUlrString("https://github.com/"));
}
这样就不会死锁了。
ConfigureAwait
除了AsyncHelper我们还可以使用Task的ConfigureAwait方法来避免死锁
private void button7_Click(object sender, EventArgs e)
{
label1.Text = GetUlrString("https://github.com/").Result;
}
public async Task<string> GetUlrString(string url)
{
using (HttpClient http = new HttpClient())
{
return await http.GetStringAsync(url).ConfigureAwait(false);
}
}
ConfigureAwait的作用：使当前async方法的await后续操作不需要恢复到主线程（不需要保存线程上下文）。
异常处理
关于新异步里面抛出异常的正确姿势。我们先来看下面一段代码：
private async void button8_Click(object sender, EventArgs e)
{
Task<string> task = GetUlrStringErr(null);
Thread.Sleep(1000);//一段逻辑。。。。
textBox1.Text = await task;
}
public async Task<string> GetUlrStringErr(string url)
{
if (string.IsNullOrWhiteSpace(url))
{
throw new Exception("url不能为空");
}
using (HttpClient http = new HttpClient())
{
return await http.GetStringAsync(url);
}
}
调试执行执行流程：
在执行完118行的时候竟然没有把异常抛出来？这不是逆天了吗。非得在等待await执行的时候才报错，显然119行的逻辑执行是没有什么意义的。让我们把异常提前抛出：
提取一个方法来做验证，这样就能及时的抛出异常了。有朋友会说这样的太坑爹了吧，一个验证还非得另外写个方法。接下来我们提供一个没有这么坑爹的方式：
在异步函数里面用匿名异步函数进行包装，同样可以实现及时验证。
感觉也不比前种方式好多少...可是能怎么办呢。
异步的实现
上面简单分析了新异步能力和属性。接下来让我们继续揭秘异步的本质，神秘的外套下面究竟是怎么实现的。
首先我们编写一个用来反编译的示例：
class MyAsyncTest
{
public async Task<string> GetUrlStringAsync(HttpClient http, string url, int time)
{
await Task.Delay(time);
return await http.GetStringAsync(url);
}
}
反编译代码：
为了方便阅读，我们把编译器自动命名的类型重命名。
GetUrlStringAsync 方法变成了如此模样：
public Task<string> GetUrlStringAsync(HttpClient http, string url, int time)
{
GetUrlStringAsyncdStateMachine stateMachine = new GetUrlStringAsyncdStateMachine()
{
_this = this,
http = http,
url = url,
time = time,
_builder = AsyncTaskMethodBuilder<string>.Create(),
_state = -1
};
stateMachine._builder.Start(ref stateMachine);
return stateMachine._builder.Task;
}
方法签名完全一致，只是里面的内容变成了一个状态机 GetUrlStringAsyncdStateMachine 的调用。此状态机就是编译器自动创建的。下面来看看神秘的状态机是什么鬼：
private sealed class GetUrlStringAsyncdStateMachine : IAsyncStateMachine
{
public int _state;
public MyAsyncTest _this;
private string _str1;
public AsyncTaskMethodBuilder<string> _builder;
private TaskAwaiter taskAwaiter1;
private TaskAwaiter<string> taskAwaiter2;
//异步方法的三个形参都到这里来了
public HttpClient http;
public int time;
public string url;
private void MoveNext()
{
string str;
int num = this._state;
try
{
TaskAwaiter awaiter;
MyAsyncTest.GetUrlStringAsyncdStateMachine d__;
string str2;
switch (num)
{
case 0:
break;
case 1:
goto Label_00CD;
default:
//这里是异步方法 await Task.Delay(time);的具体实现
awaiter = Task.Delay(this.time).GetAwaiter();
if (awaiter.IsCompleted)
{
goto Label_0077;
}
this._state = num = 0;
this.taskAwaiter1 = awaiter;
d__ = this;
this._builder.AwaitUnsafeOnCompleted<TaskAwaiter, MyAsyncTest.GetUrlStringAsyncdStateMachine>(ref awaiter, ref d__);
return;
}
awaiter = this.taskAwaiter1;
this.taskAwaiter1 = new TaskAwaiter();
this._state = num = -1;
Label_0077:
awaiter.GetResult();
awaiter = new TaskAwaiter();
//这里是异步方法await http.GetStringAsync(url);的具体实现
TaskAwaiter<string> awaiter2 = this.http.GetStringAsync(this.url).GetAwaiter();
if (awaiter2.IsCompleted)
{
goto Label_00EA;
}
this._state = num = 1;
this.taskAwaiter2 = awaiter2;
d__ = this;
this._builder.AwaitUnsafeOnCompleted<TaskAwaiter<string>, MyAsyncTest.GetUrlStringAsyncdStateMachine>(ref awaiter2, ref d__);
return;
Label_00CD:
awaiter2 = this.taskAwaiter2;
this.taskAwaiter2 = new TaskAwaiter<string>();
this._state = num = -1;
Label_00EA:
str2 = awaiter2.GetResult();
awaiter2 = new TaskAwaiter<string>();
this._str1 = str2;
str = this._str1;
}
catch (Exception exception)
{
this._state = -2;
this._builder.SetException(exception);
return;
}
this._state = -2;
this._builder.SetResult(str);
}
[DebuggerHidden]
private void SetStateMachine(IAsyncStateMachine stateMachine)
{
}
}
明显多个异步等待执行的时候就是在不断调用状态机中的MoveNext()方法。经验来至我们之前分析过的IEumerable,不过今天的这个明显复杂度要高于以前的那个。猜测是如此，我们还是来验证下事实：
在起始方法 GetUrlStringAsync 第一次启动状态机 stateMachine._builder.Start(ref stateMachine);
确实是调用了 MoveNext 。因为_state的初始值是-1，所以执行到了下面的位置：
绕了一圈又回到了 MoveNext 。由此，我们可以现象成多个异步调用就是在不断执行MoveNext直到结束。
说了这么久有什么意思呢，似乎忘记了我们的目的是要通过之前编写的测试代码来分析异步的执行逻辑的。
再次贴出之前的测试代码，以免忘记了。
反编译后代码执行逻辑图：
当然这只是可能性较大的执行流程，但也有 awaiter.Iscompleted 为 true 的情况。其他可能的留着大家自己去琢磨吧。
本文已同步至索引目录：《C#基础知识巩固》
浙公网安备 33010602011771号