.NET Core学习笔记(4)——谨慎混合同步和异步代码

关于博客园内嵌入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线程进退不得。这样不同的迷惑行为,即使是十分年长的猿类也瑟瑟发抖……

.NET Core学习笔记(4)——谨慎混合同步和异步代码

最理想的情况就是只编写异步代码。问题是除非编写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

.NET Core学习笔记(4)——谨慎混合同步和异步代码

 

JDK 1.8 完整日期时间Api (文末附示例)

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享