async/await 的基本实现和 .NET Core 2.1 中相关性能提升

前言

这篇文章的开头,笔者想多说两句,不过也是为了以后再也不多嘴这样的话。

在日常工作中,笔者接触得最多的开发工作仍然是在 .NET Core 平台上,当然因为团队领导的开放性和团队风格的多样性(这和 CTO 以及主管的个人能力也是分不开的),业界前沿的技术概念也都能在上手的项目中出现。所以虽然现在团队仍然处于疾速的发展中,也存在一些奇奇怪怪的事情,工作内容也算有紧有松,但是总体来说也算有苦有乐,不是十分排斥。

其实这样的环境有些类似于笔者心中的“圣地” Thoughtworks 的 雏形(TW的HR快来找我啊),笔者和女朋友谈到自己最想做的工作也是技术咨询。此类技术咨询公司的开发理念基本可以用一句概括:遵循可扩展开发,可快速迭代,可持续部署,可的架构设计,追求目标应用场景下最优于团队的技术选型决策

所以语言之争也好,平台之争也好,落到每一个对编程和解决问题感兴趣的开发者身上,便成了最微不足道的问题。能够感受不同技术间的碰撞,领略到不同架构思想中的精妙,就已经是一件满足的事情了,等到团队需要你快速应用其他技术选型时,之前的努力也是助力。当然面向工资编程也是一种取舍,笔者思考的时候也会陷入这个怪圈,所以希望在不断的学习和实践中,能够让自己更满意吧。

著名的 DRY 原则告诉我们 —— Don‘t repeat yourself,而笔者想更进一步的是,Deep Dive And Wide Mind,深入更多和尝试更多。

奇怪的前言就此结束。

作为最新的正式版本,虽然版本号只是小小的提升,但是 .NET Core 2.1 相比 .NET Core 2.0 在性能上又有了大大的提升。无论是项目构建速度,还是字符串操作,网络传输和 JIT 内联方法性能,可以这么说的是,如今的 .NET Core 已经主动为开发者带来抠到字节上的节省体验。具体的介绍还请参看 Performance Improvements in .NET Core 2.1

而在这篇文章里,笔者要聊聊的只是关于 async/await 的一些底层原理和 .NET Core 2.1 在异步操作对象分配上的优化操作。

async/await 实现简介

熟悉异步操作的开发者都知道,async/await 的实现基本上来说是一个骨架代码(Template method)和状态机。

从反编译器中我们可以窥见骨架方法的全貌。假设有这样一个示例程序

internal class Program
{
    private static void Main()
    {
        var result = AsyncMethods.CallMethodAsync("async/await").GetAwaiter().GetResult();

        Console.WriteLine(result);
    }
}

internal static class AsyncMethods
{
    internal static async Task<int> CallMethodAsync(string arg)
    {
        var result = await MethodAsync(arg);

        await Task.Delay(result);

        return result;
    }

    private static async Task<int> MethodAsync(string arg)
    {
        var total = arg.First() + arg.Last();

        await Task.Delay(total);

        return total;
    }
}

为了能更好地显示编译代码,特地将异步操作分成两个方法来实现,即组成了一条异步操作链。这种“侵入性”传递对于开发其实是更友好的,当代码中的一部分采用了异步代码,整个传递链条上便不得不采用异步这样一种正确的方式。接下来让我们看看编译器针对上述异步方法生成的骨架方法和状态机(也已经经过美化产生可读的C#代码)。

[DebuggerStepThrough]
[AsyncStateMachine((typeof(CallMethodAsyncStateMachine)]
private static Task<int> CallMethodAsync(string arg)
{
    CallMethodAsyncStateMachine stateMachine = new CallMethodAsyncStateMachine {
        arg = arg,
        builder = AsyncTaskMethodBuilder<int>.Create(),
        state = -1
    };
    stateMachine.builder.Start<CallMethodAsyncStateMachine>(
    (ref stateMachine)=>
    {
        // 骨架方法启动第一次 MoveNext 方法
        stateMachine.MoveNext();
    });

    return stateMachine.builder.Task;
}

[DebuggerStepThrough]
[AsyncStateMachine((typeof(MethodAsyncStateMachine)]
private static Task<int> MethodAsync(string arg)
{
    MethodAsyncStateMachine stateMachine = new MethodAsyncStateMachine {
        arg = arg,
        builder = AsyncTaskMethodBuilder<int>.Create(),
        state = -1
    };

    // 恢复委托函数
    Action __moveNext = () =>
    {
        stateMachine.builder.Start<CallMethodAsyncStateMachine>(ref stateMachine);
    }

    __moveNext();

    return stateMachine.builder.Task;
}
  • MethodAsync/CallMethodAsync - 骨架方法
  • MethodAsyncStateMachine/CallMethodAsyncStateMachine - 每个 async 标记的异步操作都会产生一个骨架方法和状态机对象
  • arg - 显然原始代码上有多少个参数,生成的代码中就会有多少个字段
  • __moveNext - 恢复委托函数,对应状态机中的 MoveNext 方法,该委托函数会在执行过程中作为回调函数返回给对应Task的 Awaiter 从而使得 MoveNext 持续执行
  • builder - 该结构负责连接状态机和骨架方法
  • state - 始终从 -1 开始,方法执行时状态也是1,非负值代表一个后续操作的目标,结束时状态为 -2
  • Task - 代表当前异步操作完成后传播的任务,其内包含正确结果

可以看到,每个由 async 关键字标记的异步操作都会产生相应的骨架方法,而状态机也会在骨架方法中创建并运行。以下是实际的状态机内部代码,让我们用实际进行包含两步异步操作的 CallMethodAsyncStateMachine 做例子。

[CompilerGenerated]
private sealed class CallMethodAsyncStateMachine : IAsyncStateMachine
{
    public int state;
    public string arg;  // 代表变量

    public AsyncTaskMethodBuilder<int> builder;

    // 代表 result
    private int result; 

    // 代表 var result = await MethodAsync(arg);
    private Task<int> firstTaskToAwait;  

    // 代表 await Task.Delay(result);
    private Task secondTaskToAwait; 

    private void MoveNext()
    {
        try
        {
            switch (this.state) // 初始值为-1
            {
                case -1:
                    // 执行 await MethodAsync(arg);
                    this.firstTaskToAwait = AsyncMethods.MethodAsync(this.arg);

                    // 当 firstTaskToAwait 执行完毕
                    this.result = firstTaskToAwait.Result;
                    this.state = 0;

                    // 调用 this.MoveNext();
                    this.Builder.AwaitUnsafeOnCompleted(ref this.awaiter, ref this);
                case 0:
                    // 执行 Task.Delay(result)
                    this.secondTaskToAwait = Task.Delay(this.result);

                    // 当 secondTaskToAwait 执行完毕
                    this.state = 1;

                    // 调用 this.MoveNext();
                    this.builder.AwaitUnsafeOnCompleted(ref this.awaiter, ref this);
                case 1:
                    this.builder.SetResult(result);
                    return;
            }
        }
        catch (Exception exception)
        {
            this.state = -2;
            this.builder.SetException(exception);
            return;
        }
    }

    [DebuggerHidden]
    private void SetStateMachine(IAsyncStateMachine stateMachine)
    {
    }
}

可以看到一个异步方法内含有几个异步方法,状态机便会存在几种分支判断情况。根据每个分支的执行情况,再通过调用 MoveNext 方法确保所有的异步方法能够完整执行。更进一步,看似是 switch 和 case 组成的分支方法,实质上仍然是一条异步操作执行和传递的Chain。

上述的 CallMethodAsync 方法也可以转化成以下 Task.ContinueWith 形式:

internal static async Task<int> CallMethodAsync(string arg)
{
    var result = await (
                    await MethodAsync(arg).ContinueWith(async MethodAsyncTask =>
                        {
                            var methodAsyncTaskResult = await MethodAsyncTask;
                            Console.Write(methodAsyncTaskResult);
                            await Task.Delay(methodAsyncTaskResult);
                            return methodAsyncTaskResult;
                        }));

    return result;
}

可以这样理解的是,总体看来,编译器每次遇到 await,当前执行的方法都会将方法的剩余部分注册为回调函数(当前 await 任务完成后接下来要进行的工作,也可能包含 await 任务,仍然可以顺序嵌套),然后立即返回(return builder.Task)。 剩余的每个任务将以某种方式完成其操作(可能被调度到当前线程上作为事件运行,或者因为使用了 I/O 线程执行,或者在单独线程上继续执行,这其实并不重要),只有在前一个 await 任务标记完成的情况下,才能继续进行下一个 await 任务。有关这方面的奇思妙想,请参阅《通过 Await 暂停和播放》

.NET Core 2.1 性能提升

上节关于编译器生成的内容并不能完全涵盖 async/await 的所有实现概念,甚至只是其中的一小部分,比如笔者并没有提到可等待模式(IAwaitable)和执行上下文(ExecutionContext)的内容,前者是 async/await 实现的指导原则,后者则是实际执行异步代码,返回给调用者结果和线程同步的操控者。包括生成的状态机代码中,当第一次执行发现任务并未完成时(!awaiter.isCompleted),任务将直接返回。

主要原因便是这些内容讲起来怕是要花很大的篇幅,有兴趣的同学推荐去看《深入理解C#》和 ExecutionContext

异步代码能够显著提高服务器的响应和吞吐性能。但是通过上述讲解,想必大家已经认识到为了实现异步操作,编译器要自动生成大量的骨架方法和状态机代码,应用通常也要分配更多的相关操作对象,线程调度同步也是耗时耗力,这也意味着异步操作运行性能通常要比同步代码要差(这和第一句的性能提升并不矛盾,体重更大的人可能速度降低了,但是抗击打能力也更强了)。

但是框架开发者一直在为这方面的提升作者努力,最新的 .NET Core 2.1 版本中也提到了这点。原本的应用中,一个基于 async/await 操作的任务将分配以下四个对象:

  1. 返回给调用方的Task
    任务实际完成时,调用方可以知道任务的返回值等信息
  2. 装箱到堆上的状态机信息
    之前的代码中,我们用了ref标识一开始时,状态机实际以结构的形式存储在栈上,但是不可避免的,状态机运行时,需要被装箱到堆上以保留一些运行状态
  3. 传递给Awaiter的委托
    即前文的_moveNext,当链中的一个 Task 完成时,该委托被传递到下一个 Awaiter 执行 MoveNext 方法。
  4. 存储某些上下文(如ExecutionContext)信息的状态机执行者(MoveNextRunner

Performance Improvements in .NET Core 2.1 一文介绍:

for (int i = 0; i < 1000; i++)
{
    await Yield();
    async Task Yield() => await Task.Yield();
}

当前的应用将分配下图中的对象:

而在 .NET Core 2.1 中,最终的分配对象将只有:

四个分配对象最终减少到一个,分配空间也缩减到了过去的一半。更多的实现信息可以参考 Avoid async method delegate allocation

结语

本文主要介绍了 async/await 的实现和 .NET Core 2.1 中关于异步操作性能优化的相关内容。因为笔者水平一般,文章篇幅有限,不能尽善尽美地解释完整,还希望大家见谅。

无论是在什么平台上,异步操作都是重要的组成部分,而笔者觉得任何开发者在会用之余,都应该更进一步地适当了解背后的故事。具体发展中,C# 借鉴了 F#中的异步实现,其他语言诸如 js 可能也借鉴了 C# 中的部分内容,当然一些基本术语,比如回调或是 feature,任何地方都是相似的,怎么都脱离不开计算机体系,这也说明了编程基础的重要性。

参考文献

  1. 通过 Await 暂停和播放
  2. 通过新的 Visual Studio Async CTP 更轻松地进行异步编程

原文地址:https://www.cnblogs.com/Wddpct/p/9002242.html

时间: 2024-10-30 06:29:42

async/await 的基本实现和 .NET Core 2.1 中相关性能提升的相关文章

教你正确打开async/await关键字的使用

这段时间在项目开发中看到了一些async/await的使用,在aspnet core的host组件源码中也看到了许多的async/await代码.在开发时,正确的使用了async/await是可以提高程序的性能.下面的代码教你正确的理解await关键字的暂停/阻塞方法调用: static void Main(string[] args) { Console.WriteLine("-------主线程启动-------"); var task = GetStrLengthAsync();

Javascript中的async await

async / await是ES7的重要特性之一,也是目前社区里公认的优秀异步解决方案.目前,async / await这个特性已经是stage 3的建议,可以看看TC39的进度,本篇文章将分享async / await是如何工作的,阅读本文前,希望你具备Promise.generator.yield等ES6的相关知识. 在详细介绍async / await之前,先回顾下目前在ES6中比较好的异步处理办法.下面的例子中数据请求用Node.js中的request模块,数据接口采用Github v3

ES6 Async/Await 完爆Promise的6个原因

自从Node的7.6版本,已经默认支持async/await特性了.如果你还没有使用过他,或者对他的用法不太了解,这篇文章会告诉你为什么这个特性"不容错过".本文辅以大量实例,相信你能很轻松的看懂,并了解Javascript处理异步的一大杀器. 文章灵感和内容借鉴了6 Reasons Why JavaScript's Async/Await Blows Promises Away (Tutorial),英文好的同学可以直接戳原版参考. 初识Async/await 对于还不了解Async

【译】.NET Core 3.0 中的新变化

.NET Core 3.0 是 .NET Core 平台的下一主要版本.本文回顾了 .Net Core 发展历史,并展示了它是如何从基本支持 Web 和数据工作负载的版本 1,发展成为能够运行 Web.桌面.机器学习.容器.IoT 等的版本 3.0. .NET Core 1 .NET Core 的历史可追溯到几年前,版本 1 是在 2016 年推出,旨在生成第一版开放源代码和跨平台(Windows.macOS 和 Linux)的 .NET.灵感来源于只能使用开放源代码框架的客户,以及需要在 Li

ASP.NET Core Web 应用程序系列(四)- ASP.NET Core 异步编程之async await

原文:ASP.NET Core Web 应用程序系列(四)- ASP.NET Core 异步编程之async await PS:异步编程的本质就是新开任务线程来处理. 约定:异步的方法名均以Async结尾. 实际上呢,异步编程就是通过Task.Run()来实现的. 了解线程的人都知道,新开一个线程来处理事务这个很常见,但是在以往是没办法接收线程里面返回的值的.所以这时候就该await出场了,await从字面意思不难理解,就是等待的意思. 执行await的方法必须是async修饰的,并且是Task

深入理解Async/Await(转)

C# 5 Async/Await 语法特性,极大地简化了异步编程,但我们知道,异步编程的基本原理并没有发生根本改变.也就是说,当一些复杂的东西看起来很简单时,它通常意味着有一些有趣的事情在背后发生.在计算机程序设计语言领域,我们把这些本身很复杂但看起来很简单的语言特性称为语法糖,通常情况下,我们并不需要深入理解语法糖是怎么被一层一层包裹起来的,但是,最近我在使用.NET Core实现MySQL协议过程中,需要实现一个Awaitable Socket,所以我需要知道Async/Await背后到底发

[译]async/await中使用阻塞式代码导致死锁

原文:[译]async/await中使用阻塞式代码导致死锁 这篇博文主要是讲解在async/await中使用阻塞式代码导致死锁的问题,以及如何避免出现这种死锁.内容主要是从作者Stephen Cleary的两篇博文中翻译过来. 原文1:Don'tBlock on Async Code 原文2:why the AspNetSynchronizationContext was removed 示例代码:async_await中使用阻塞式代码导致死锁.rar 一.async/await 异步代码运行流

传统asp.net小心 async/await坑

最近在改老项目时,干了一件自以为很有成就感的事,心想 "项目都是同步方法,为啥不用异步方法呢?",于是有了异步方法,类型下面的代码(当然是举例子说明啊) //更新某人名下公司名称 public Task<bool> UpdateUser(string id,string companyName) { var usrInfo=Db.GetUsrInfo(id); var flag= await Db.UpdateCompanyNameAsync(usrInfo.company

异步编程之Async,Await和ConfigureAwait的关系

在.NET Framework 4.5中,async / await关键字已添加到该版本中,简化多线程操作,以使异步编程更易于使用.为了最大化利用资源而不挂起UI,你应该尽可能地尝试使用异步编程.虽然async / await让异步编程更简单,但是有一些你可能不知道的细节和注意的地方  新关键字 微软在.NET框架中添加了async和await关键字.但是,使用它们,方法的返回类型应为Task类型.(我们将在稍后讨论例外情况)为了使用await关键字,您必须在方法定义中使用async.如果你在方