接上篇：30分钟？不需要，轻松读懂IL，这篇主要从IL入手来理解async/await的工作原理。 先简单介绍下async/await，这是.net 4.5引入的语法糖，配合Task使用可以非常优雅
对async/await的支持已经存在了十多年。它的出现，改变了为 .NET 编写可伸缩代码的方式，你在不了解幕后的情况下也可以非常普遍地使用该功能。
最近在准备.NET Go核心能力的深度对比.note， 关于.NET/Go的异步实现总感觉没敲到点上。
基本介绍 Async、Await是net4.x新增的异步编程方式，其目的是为了简化异步程序编写，和之前APM方式简单对比如下。 APM方式，BeginGetRequestStream需要传入回调函数，线程碰到BeginXXX时会以非阻塞形式继续执行下面逻辑，完成后回调先前传入的函数。 HttpWebRequest myReq =(HttpWebRequest)WebRequest.Create("http://cnblogs.com/"); myReq.BeginGetRequestSt
上面是关于异步编程的解释，我们日常编程过程或多或少的会使用到异步编程，为什么要试用异步编程？因为用程序处理过程中使用文件和网络 I/O，比如处理文件的读取写入磁盘，网络请求接口API，默认情况下 I/O API 一般会阻塞。 这样的结果是导致我们的用户界面卡住体验差，有些服务器的硬件利用率低，服务处理能力请求响应慢等问题。基于任务的异步 API 和语言级异步编程模型改变了这种模型，只需了解几个新概念就可默认进行异步执行。
从4.0版本开始.NET引入并行编程库，用户能够通过这个库快捷的开发并行计算和并行任务处理的程序。在4.5版本中.NET又引入了Async和Await两个新的关键字，在语言层面对并行编程给予进一步的支持，使得用户能以一种简洁直观的方式实现并行编程。因为在很多文档里针对Async和Await这两个关键字的使用都被称为异步编程，为了更符合大众的阅读习惯，我们使用异步编程这个叫法，意思上和并行编程完全一样。
每次用到的时候新创建一个状态机，太奢侈了，官方文档里面也提到过这点。而且创建出来的实例，其状态也跟当前订单的不符；spring statemachine暂时不支持每次创建时指定当前状态，所以对状态机引擎实例的持久化，就成了必须要考虑的问题。
在c#中，异步的async和await原理，以及运行机制，可以说是老生常谈，经常在各个群里看到有在讨论这个的，而且网上看到的也只是对异步状态机的一些讲解，甚至很多人说异步状态机的时候，他们说的是在运行时去构建状态机对线程状态进行调度，实际上异步状态机是属于编译期间，通过生成dll，然后我们使用反编译工具查看，是可以看到IL构建了异步状态机，并且在运行时添加了两个特性，其中比较重要的是AsyncStateMachine特性这个特性接受的是一个type类型的参数，即指定用的是哪一个异步状态机。所以在写多线程的时候，前面第一篇主要写线程方面的一些具体的使用，以及实现自定义的一些操作，接下来的这篇可能会注重原理方面的讲解，以及结合一些代码实现自定义状态机。
Task对于.NET的重要性毋庸置疑。通过最近的一些面试经历，发现很多人对与Task及其调度机制，以及线程和线程池之间的关系并没有清晰的认识。本文采用最简单的方式模拟了Task的实现，旨在说明Task是什么？它是如何被调度执行的？源代码从这里下载。
在平常的后端项目开发中，状态机模式的使用其实没有大家想象中那么常见，笔者之前由于不在电商领域工作，很少在业务代码中用状态机来管理各种状态，一般都是手动get/set状态值。去年笔者进入了电商领域从事后端开发。电商领域，状态又多又复杂，如果仍然在业务代码中东一块西一块维护状态值，很容易陷入出了问题难于Debug，难于追责的窘境。
前言 这篇文章的开头，笔者想多说两句，不过也是为了以后再也不多嘴这样的话。 在日常工作中，笔者接触得最多的开发工作仍然是在 .NET Core 平台上，当然因为团队领导的开放性和团队风格的多样性（这和 CTO 以及主管的个人能力也是分不开的），业界前沿的技术概念也都能在上手的项目中出现。所以虽然现在团队仍然处于疾速的发展中，也存在一些奇奇怪怪的事情，工作内容也算有紧有松，但是总体来说也算有苦有乐，不是十分排斥。 其实这样的环境有些类似于笔者心中的“圣地” Thoughtworks 的 雏形（TW的HR快来找
博客园中有很多关于 .NET async/await 的介绍，但是很遗憾，很少有正确的，甚至说大多都是“从现象编原理”都不过分。
cola-statemachine是阿里开源项目COLA (opens new window)中的轻量级状态机组件。最大的特点是无状态、采用纯Java实现，用Fluent Interface(连贯接口)定义状态和事件，可用于管理状态转换场景。比如：订单状态、支付状态等简单有限状态场景。在实际使用的过程中我曾发现状态机内事务不生效的问题，经过排查得到解决，以此记录一下。
在电商领域，很多业务对象都是有状态的，且这些对象的状态又多又复杂。硬编码的方式已经不适合管理当前复杂业务对象的状态。为了适配复杂多变的业务，可以使用状态机来管理状态，统一定义业务对象状态和状态的流转。接下来，本文会重点介绍状态机相关的概念和使用场景。
目录 1，可用版本与参考资料 2，ValueTask 和 Task 3，编译器如何编译 4，ValueTask 有什么优势 5，ValueTask 创建异步任务 6，IValueTaskSource 和自定义包装 ValueTask 关于 IValueTaskSource 什么是 IValueTaskSource 再说 ValueTask 优势 不要自己全部实现 IValueTaskSource ValueTaskSourceOnCompletedFlags ValueTaskSourceStatus 7，
之前在上一篇文章中多线程合集(二)---异步的那些事，async和await原理抛析，我们从源码去分析了async和await如何运行，以及将编译后的IL代码写成了c#代码，以及实现自定义的Awaiter，自定义异步状态机同时将本系列的第一篇文章的自定义TaskScheduler和自定义的Awaiter结合起来，将代码跑了起来，而在c#10之后，我们可以实现自定义的异步生成器，在上一篇文章中，我们将编译后的代码还原成了c#代码，其中就有用到了一个AsyncTaskMethodBuilder的类，搁以前我们只能使用编译器编译之后的AsyncTaskMethodBuilder，现在我们已经可以自定义了，如果再加上上一章节的自定义状态机，加调度，可能会更好玩一些，接下来就为大家奉上代码。
在开发中总会遇到这样的场景，比如工单状态，流程状态，通过状态判断该执行的操作，不断改动的需求导致永无止境的 IF、ELSE 和 BREAK 子句的层次结构，当事情开始看起来太复杂时，简直就像面满池子的海洋球。
营销自动化平台支持多种不同类型运营活动策略（比如：短信推送策略、微信图文推送策略、App Push推送策略），每种活动类型都有各自不同的执行流程和活动状态。比如短信活动的活动执行流程如下：
首先我们知道async await 异步函数本质是状态机,我们通过反编译工具dnspy，看看反编译的两段代码是否有不同之处：
上一篇文章《关于状态机的技术选型，最后一个真心好》我跟大家聊了一下关于”状态机“的话题。从众多技术选型中我也推荐了一款阿里开源的状态机—“cola-statemachine”。
C#的yield关键字由来以久，如果我没有记错的话，应该是在C# 2.0中被引入的。相信大家此关键字的用法已经了然于胸，很多人也了解yield背后的“延迟赋值”机制。但是即使你知道这个机制，你也很容易在不经意间掉入它制造的陷阱。 目录 一、一个很简单的例子 二、简单谈谈“延迟赋值” 三、从反射的代码帮助我们更加直接的了解yield导致的延迟赋值 四、如果需要“立即赋值”怎么办？ 后记 一、一个很简单的例子 下面是一个很简单的例子：Vector为
这里很清楚的看到,尝试把状态机对象(实际是状态机的包装类),赋值到 Task.m_continuationObject, 如果操作失败,则把状态机对象丢进线程池等待调度,这里为什么这么实现,看一下线程池是怎么执行的就清楚了
本文将详解C#类当中的Task，以及异步函数async await和Task的关系
https://docs.spring.io/spring-statemachine/docs/current/reference/#configuring-guards
在分析Seata的saga模式实现时，实在是被其复杂的 json 状态语言定义文件劝退，我是有点没想明白为啥要用这么来实现状态机；盲猜可能是基于可视化的状态机设计器来定制化流程，更方便快捷且上手快吧，毕竟可以通过UI直接操作，设计状态流转图，但我暂时不太能get到。对于Saga模式的实现，之前的博文中已经阐述了基于状态机模式实现Saga，是比较常见且合适的做法，因此了解了下Java中的状态机实现方案，以后有相关的业务场景也可以直接上手使用状态机。
状态机是“有限状态自动机”的简称，是一种描述和处理事物状态变化的数学模型。本质上来讲，就是一种比if...else结构更加优雅，并具备可扩展性的状态转移处理机制。有多种实现方案，如：枚举，Spring Statemachine，cola state machine。
https://docs.spring.io/spring-statemachine/docs/current/reference/#state-machine-via-builder
在实际的项目开发中，开发者经常会遇见类似多级审核之类的开发需求，比如某个文件审核，需要经过申请->直系领导审核->总经理审核等多个步骤。如果是一次动作触发整个审核过程，开发者可能会想到使用责任链模式来进行开发。但如果多级审核的间隔时间长，审核触发的条件不一样，责任链模式会不太能够解耦这项需求。如果采用平铺直叙式开发，无疑会将审核状态转移过程散落在系统间各个位置，前后两个状态之间的关系没有直观进行维护，同时状态转移时的条件、执行的方式和状态之间的逻辑关系很容易让开发者写出“面条代码”。在项目开发初期可能还好，随着需求的增量变化，平铺直叙式开发将使得状态转移逻辑和业务逻辑高度混合，且每增加一级节点审核，就要新增对应的审核状态及状态转移的逻辑，长此以往变得难以阅读和维护。所以，在这种情况下使用状态机这样建模方式就显得尤为必要。
以为缺少对应的包，然后去nuget安装时发现 最新版本是2.2 ，跟.NETcore web 项目引用的版本不一样。
状态机是古老的计算机理论，在游戏开发、嵌入式开发、网络协议等领域，得到广泛地使用。
正文 缘起 1、哈喽大家中秋节（后）好呀！感觉已经好久没有写文章了，但是也没有偷懒哟，我的视频教程《系列一、NetCore 视频教程（Blog.Core）》也已经录制八期了，还在每周末同步更新中，欢迎
缘起 1、哈喽大家中秋节（后）好呀！感觉已经好久没有写文章了，但是也没有偷懒哟，我的视频教程《系列一、NetCore 视频教程（Blog.Core）》也已经录制八期了，还在每周末同步更新中，欢迎大家多多指教。 2、除此之外呢，我也在平时的时间帮朋友开发了一个小项目，就是使用 .net mvc+vue+ele+mongo 框架写的项目，之前一直想着用mvc结合着vue写，这次也终于上手了，不过是一个小的demo，因为是朋友的项目，所以就不开源了。 言归正传，👉 从2018年8月就开始听说 netcore 要
今天想跟大家分享一个关于“状态机”的话题。状态属性在我们的现实生活中无处不在。比如电商场景会有一系列的订单状态(待支付、待发货、已发货、超时、关闭）；员工提交请假申请会有申请状态（已申请、审核中、审核成功、审核拒绝、结束）；差旅报销单会有单据审核状态（已提交、审核中、审核成功、退回、打款中、打款成功、打款失败、结束）等等。
很多业务系统开发中，不可避免的会出现状态变化，通常采用的情形可能是使用工作流去完成，但是对于简单场景下，用工作流有点大财小用感觉，比如订单业务中，订单状态的变更，涉及到的状态量不是很多，即使通过简单的if-else也能足够使用，甚至是用上switch去减少if-else的使用，都是可以的，尽管这会丧失某些东西。为更好的优化整个流程，此时会考虑到使用状态模式来解决一些问题。
在《vivo 营销自动化技术解密 |开篇》中，我们从整体上介绍了vivo营销自动化平台的业务架构、核心业务模块功能、系统架构和几大核心技术设计。
这边文章主要是对netcore中的配置框架做一个实战详解，篇幅较长内容涉及比较多，请耐心阅读并进行尝试，均采用控制台程序进行展示。 环境： netcore 3.1.4 win10 vs 2019 16.5.5
一、State 状态 1.核心属性 /// /// 状态名称 /// public string Name { get; set; } 2.核心事件 OnInitialization 状态初始化事件 OnEnter 状态进入事件 OnStay 状态停留事件 OnExit 状态退出事件 OnTermination 状态终止事件 public class ExampleState : State { public ove
缓存可以减少生成内容所需的工作，从而显著提高应用程序的性能和可伸缩性。 缓存最适用于不经常更改的 数据，生成 成本很高。 通过缓存，可以比从数据源返回的数据的副本速度快得多。 应该对应用进行编写和测试，使其 永不 依赖于缓存的数据。
状态机之所以强大，是因为其行为在启动时就以固定的方式定义了操作规则，从而确保了一贯的连贯性和相对较高的可调试性。关键在于，应用程序处于且仅可能处于有限数量的状态中。然后，某些事件发生会使得应用从一个状态过渡到另一个状态。状态机由触发器驱动，这些触发器基于事件或计时器。
在早之前的文章《YARN——任务提交启动流程》中提到了，其处理逻辑是围绕applicaiton、container、attempt实例对象的创建，各自状态机的变化来实现的。
公司对底层基础库进行了重构，线上稳定跑了几天，在查看订单系统的log时，有几条error信息非常的奇怪，
本文将以电商项目中的订单状态转换这个典型的场景。从订单的创建到支付、发货、完成等状态来使用状态机进行管理。如果使用传统的if-else或者switch语句来管理这些状态，代码会变得非常臃肿且难以维护。而状态机提供了一种更加结构化和可维护的方式来管理这些状态转换。
(译)状态机的实现探讨 原文链接地址：http://drdobbs.com/cpp/184401236?pgno=1 实现一个状态机很容易，但是实现一个好的状态机却不简单。一般实现状
有限状态机（Finite-state machine）是一个非常有用的模型，可以模拟世界上大部分事物。 简单说，它有三个特征： * 状态总数（state）是有限的。 * 任一时刻，只处在一
本文介绍如何为FSM有限状态机模块实现一个自定义编辑器面板，FSM的代码在如下链接中有详细介绍：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
