关于博客园内嵌入bilibili视频
原则上我们应该避免编写混合同步和异步的代码,这其中最大的问题就是很容易出现死锁。让我们来看下面的例子:
private void ButtonDelayBlock_Click(object sender, RoutedEventArgs e) { Delay100msAsync().Wait(); this.buttonDelayBlock.Content = "Done"; } private async Task Delay100msAsync() { await Task.Delay(100); }
这段代码取自Sample代码中的AsyncBlockSample工程,一个简单的WPF程序(.NET Core)。
https://github.com/manupstairs/AsyncAwaitPractice
在buttonDelayBlock按钮被点击后,会执行Dealy100msAsync方法,同时我们希望将该异步方法以同步的方式运行。在该方法完成后,将buttonDelayBlock按钮的文字设置为“Done”。
所以我们没有对Delay100msAsync方法应用await关键字,而是通过Wait方法同步等待执行结果。
非常遗憾在WPF之类的GUI程序中,我们点击buttonDelayBlock按钮后,程序将会进入死锁的状态。
这是因为一个未完成的Task被await时(Task.Delay(100)返回的Task),将捕获当前的context,用于Task完成时恢复执行接下来的操作。在GUI程序中,此时的context是当前 SynchronizationContext,而GUI程序中的 SynchronizationContext同一时间只能运行一个线程(在Sample里是UI线程)。
所以当Task.Delay(100)完成时,希望能够回到UI线程接着执行,但UI线程正通过Delay100msAsync.Wait()方法在等待Task完成。这踏马就跟吵架了都在等对方先低头,整个程序都不好了,然后就死了……
值得一提的是Console程序并不会出现上述死锁,这是因为Console程序中的SynchronizationContext可以通过ThreadPool来调度不同线程来完成Task,而不会像GUI程序卡在UI线程进退不得。这样不同的迷惑行为,即使是十分年长的猿类也瑟瑟发抖……
最理想的情况就是只编写异步代码。问题是除非编写UWP这样,从底层API调用就强制异步。不然很难避免旧有的同步API的使用。
更不用说成千上万的旧有代码的维护,迁移桌面程序到MS Store,已有GUI程序Win10 style化需求等等。混合同步和异步代码实在是难以避免的。像例子中需要等待异步方法完成,再根据结果执行的情况就更常见了。
解决上述死锁的一个方式是通过ConfigureAwait方法来配置context。
async Task MyMethodAsync() { // Code here runs in the original context. await Task.Delay(1000); // Code here runs in the original context. await Task.Delay(1000).ConfigureAwait(continueOnCapturedContext: false); // Code here runs without the original // context (in this case, on the thread pool). }
如注释所描述,第一个await Task.Delay方法前后的代码块会在相同的context中执行,因为Task完成后仍会返回原先的context。而第二个await Task.Delay则不再依赖原先的context。如果是在GUI程序中执行上面的代码,后续的代码将在ThreadPool,而不是之前的UI线程上执行。
Android教程2020 – RecyclerView显示多种item
在这种情况下如果出现了对UI元素的操作,便会出现祖传的跨线程操作Exception。
我们回到死锁的问题上,通过ConfigureAwait配置context的代码如下:
private async Task Delay100msWithoutContextAsync() { await Task.Delay(100).ConfigureAwait(false); } private void ButtonDelay_Click(object sender, RoutedEventArgs e) { Delay100msWithoutContextAsync().Wait(); this.buttonDelay.Content = "Done"; }
我们可以通过这种方式终结异步代码链的传递,将一小块的异步代码隐匿在旧有的同步代码中使用,当然仍需要十分小心。
这里还有一种略显繁琐且奇怪的方式来解决死锁问题:
private void ButtonDelay2_Click(object sender, RoutedEventArgs e) { var text = buttonDelay2.Content.ToString(); var length = Task.Run(async () => { return await GetLengthAsync(text); }).Result; buttonDelay2.Content = $"Total length is {length}"; } private async Task<int> GetLengthAsync(string text) { await Task.Delay(3000); return text.Length; }
异步方法GetLengthAsync能返回传入字符串的长度,Task.Run(…)会通过ThreadPool来异步地执行一个Func<Task<int>>,且返回Task<int>,而Task<int>.Result属性又以同步的方式阻塞在这里等待结果。
与之前Wait最大的不同,是因为Task.Run利用了ThreadPool没有导致UI线程的死锁。
我们再回到通过ConfigureAwait配置context,等待异步方法结果的方式:
private void ButtonDelay3_Click(object sender, RoutedEventArgs e) { var text = buttonDelay3.Content.ToString(); var length = GetLengthWithoutContextAsync(text).Result; buttonDelay3.Content = $"Button 3 total length is {length}"; } private async Task<int> GetLengthWithoutContextAsync(string text) { await Task.Delay(3000).ConfigureAwait(false); //Cannot access UI thead here, will throw exception //buttonDelay3.Content = $"Try to access UI thread"; return text.Length; }
同样是等待Task<type>的Result,相对而言更推荐这种方式,结构清晰且更好理解。注释提到ConfigureAwait(false)之后的代码是不能访问UI线程的。
本篇讨论了混合同步和异步代码时的一些注意事项,还请各位大佬斧正。
Github:
https://github.com/manupstairs/AsyncAwaitPractice
JDK 1.8 完整日期时间Api (文末附示例)