1.Rust Async: smol源码分析-Executor篇
2.kotlin之协程(六),协程中的 async和launch的区别以及runBlocking
3.async-validator源码解析（四）：Schema类
4.async-validator源码解析（二）：rule
5.Async、Await 从源码层面解析其工作原理
6.UE4源码剖析——异步与并行 中篇 之 Thread

Rust Async: smol源码分析-Executor篇

       本文深入探讨了smol异步运行时中的Executor组件，尤其关注了Executor的实现细节。在smol的异步框架中，Executor扮演了核心角色，主要负责执行Future，javase集合源码并在多线程环境中调度和管理任务。

       Executor分为三种类型：ThreadLocalExecutor、Blocking Executor、Work Stealing Executor。ThreadLocalExecutor用于处理不能实现Send特性的Future，通过使用并发和非并发队列，减少了跨线程的同步开销。Blocking Executor则允许执行阻塞任务，并通过动态地开启线程来应对任务的增加，从而提高了资源的利用率。Work Stealing Executor则通过工作窃取的方式，实现了线程间的任务负载均衡，每个工作线程通过主动调用smol::run加入工作环境。

       在Executor的实现中，ThreadLocalExecutor通过线程局部变量来管理任务的生命周期，确保了任务与线程的绑定。Blocking Executor通过自适应地开启线程，以应对任务的增加或减少，从而保持了系统的高效运行。Work Stealing Executor通过工作窃取的方式，实现了任务在多个线程间的合理分配，提高了系统的整体性能。

       每一个Executor的实现都紧密围绕着任务的调度、执行和管理，通过不同策略满足了不同场景下的需求。ThreadLocalExecutor适用于无法实现Send特性的Future，Blocking Executor能够应对阻塞任务的执行，而Work Stealing Executor则通过动态负载均衡实现了任务的高效分配。

       在使用smol异步运行时时，ioutils源码需要注意到几个关键点。async_std的运行时采用了延迟实例化、按需自动启动的策略，简化了使用体验。然而，smol目前采用的是手动启用运行时的策略，可能导致运行时panic问题，用户需要额外的配置来启动整个工作窃取运行环境。因此，正确配置和启动smol运行时对于开发者来说是至关重要的。

       总结而言，smol的Executor组件设计精妙，通过不同类型的Executor满足了多样化的异步任务需求。其简洁而高效的设计，使得开发者能够轻松地将现有的库进行异步化处理，极大地提高了开发效率和系统性能。未来，随着smol的发展和完善，其在异步编程领域的应用将更加广泛。

kotlin之协程(六),协程中的 async和launch的区别以及runBlocking

       kotlin之协程(一),线程,进程,协程,协程可以替换线程吗?

        kotlin之协程(二),Kotlin协程是什么、挂起是什么、挂起的非阻塞式

        kotlin之协程(三),开始创建协程,launch,withContext

        kotlin之协程(四),协程的核心关键字suspend

        kotlin之协程(五),launch 函数以及协程的取消与超时

        kotlin之协程(七),协程中relay、yield 区别

        launch 函数定义：

        async 函数定义：

        从源码可以看出launch 和 async的唯一区别在于async的返回值

        async 返回的是 Deferred 类型，Deferred 继承自 Job 接口，Job有的它都有，增加了一个方法 await ，这个方法接收的是 async 闭包中返回的值，async 的特点是不会阻塞当前线程，但会阻塞所在协程，也就是挂起

        runBlocking 启动的协程任务会阻断当前线程，直到该协程执行结束。当协程执行结束之后，页面才会被显示出来。

        runBlocking 通常适用于单元测试的场景，而业务开发中不会用到这个函数

async-validator源码解析（四）：Schema类

       async-validator源码解析（四）深入核心：Schema类详解

       在上篇中我们已经探讨了rule的细节，现在我们继续向上，关注async-validator库的基石——Schema类。尽管Schema类的代码较为复杂，但本文将从非核心的结构、属性和方法入手，同时在analysis分支的GitHub仓库中可以找到详细代码分析。

       Schema类是async-validator库的典型使用方式，其构造和功能强大。首先，我们从构造函数开始解析，它分为三个步骤，其中定义方法（define）暂且跳过，因为其代码量大，会在后续章节单独讨论。kcptun源码

       Schema类的构造函数涉及到messages.js中的defaultMessages，它提供了针对不同验证失败的模板提示。这允许用户在项目中根据需要定制错误提示。文档中提供了如何使用Schema.prototype.message方法自定义message的示例。

       然而，message的深度合并存在一个局限，只能处理两层嵌套，但默认messages正好满足这一需求。关于警告控制，官方文档建议在实例化Schema前通过warning方法进行设置，以控制警告信息的显示。

       此外，Schema类还提供了静态方法register，允许用户注册自定义的校验类型，尽管官方文档对此并未详述。这为开发者扩展库的功能提供了便利。

async-validator源码解析（二）：rule

       async-validator源码解析（二）深入探讨rule模块，解析其内部的校验逻辑和依赖工具函数。本文将逐步揭开rule目录的面纱，以及util.js中关键的format和isEmptyValue方法。

       rule目录的核心是export的一系列校验方法，它们接受value、source、errors和options作为参数。value是当前字段的值，source是整个待校验的对象，而errors数组用于存储验证结果。options允许自定义验证消息。每种规则方法如required、whitespace、range等，都有特定的验证功能，例如检查必填性、空白字符、cydia源码数值范围等。

       format函数是个灵活的工具，根据传入参数的不同执行不同的格式化操作。而isEmptyValue则用于判断值是否为空，包括空字符串和空数组。

       在rule目录中，type.js规则尤其有趣，通过组合简单的判断，区分了值的多种类型，如整数、浮点数、数组等。

       后续文章将继续关注validator目录，完整揭示async-validator校验库的运作机制。点击github.com/MageeLin/asy.../analysis分支，探索每个文件的详细代码解析。

Async、Await 从源码层面解析其工作原理

       深入理解 Async 和 Await 的工作原理，往往需要从源码层面进行剖析。使用 Babel 进行转换后，可以清晰地发现 Async 和 Await 实际上借助了 switch-case 和 promise，实现对流程的控制。以一个使用 Async 和 Await 的函数为例，我们仅关注核心部分代码。

       经过 Babel 转换后的 name 函数，可以被拆分为三个主要部分：await 部分、return 部分以及 async 流程控制的结束部分（即 case "end"）。这个拆分使得流程控制变得更为直观。在流程控制中，每一步执行后，都会等待合适的时机进入下一次执行。

       这个“合适的时机”并非由 Async 内部决定，而是由执行的内容决定。例如，exaro源码在发送异步请求后，只有在请求返回后才会进入下一个 case。

       为了实现流程控制，需要借助 regenerator-runtime 这个 generator、Async 函数的运行时。它负责将 name 函数进行包装，并添加流程控制所需的信息。如 _context，以及用于流程控制的关键 helper，如 _asyncToGenerator 和 asyncGeneratorStep。通过这些辅助工具，再在 regenerator-runtime 的基础上进行一层包装，最终得到一个可以执行的函数。这个函数实际执行时，会调用封装后的函数。

       在封装后的函数中，async1、async2 等实际上是在执行最终的封装函数内部的调用。这里的第三步是 Async 函数的核心机制。在 Promise.resolve(value).then(_next) 中，value 是每个分段最后的 case 返回的值。如果 value 是一个 Promise，那么在它 resolved 后，会将其.then添加到微任务队列。如果 value 不是一个 Promise，则直接添加，因为.then是一个微任务，当执行到它时，会调用_next，从而开始执行下一个 case。

       经过转换后的代码展示了封装后的函数内容，最终执行的是封装后的函数，因此说 async1、async2 执行实际上是执行封装后的函数。在封装后的函数内部，会调用 async1、async2。

UE4源码剖析——异步与并行 中篇 之 Thread

       我们知道UE中的异步框架分为TaskGraph与Thread两种，上篇教程我们学习了TaskGraph，它擅长处理有依赖关系的短任务；本篇教程我们将学习Thread，它与TaskGraph相反，它更擅长于处理长任务。而下一篇文章，我们则会承接Thread，去学习一下引擎中一些重要的线程。

       Thread擅长处理长任务，从长任务生命周期这个层面来看，我们可以先把长任务分为两类：常驻型长任务与非常驻型长任务。

       常驻型长任务侧重于并行，通常用于监听式服务，例如网络传输，使用单独的线程对网络进行监听，每当有网络数据包到达时，线程接收并处理后，不会立即结束，而是重置部分状态，继续监听，等待下一轮数据包。

       非常驻型长任务侧重于异步，通常用于数据处理，例如主线程为了提高性能，避免卡顿，会将一些重负载的运算任务分发给分线程处理，可能分批给多条分线程，主线程继续运行其他逻辑。任务处理完成后，将结果返回给主线程，分线程可销毁。

       接下来，我们通过两个例子学习Thread的使用。

       计算由N到M（N和M为大数字）所有数字的和。使用Thread异步调用，将计算操作交由分线程执行，计算完成后再通知主线程结果，代码实现如下：

       逻辑分为两部分：启动分线程计算数字和，使用Async函数，参数为EAsyncExecution::Thread，创建新线程执行。学习Async函数用法，该函数返回TFuture对象，代表未来状态，当前无法获取结果，但在未来某个时刻状态变为Ready，此时可通过TFuture获取结果。

       主线程注册回调，等待分线程计算完成，使用TFuture的Then函数，完成时触发注册的回调，也可使用Wait系列函数等待计算完成。

       接下来学习常驻型任务使用。

       定义玩家血量上限点，当前点，当血量未满时，每0.2秒恢复1点血量。代码实现分为创建生命治疗仪FRunnable对象、重写Run函数、创建FRunnableThread线程、测试恢复功能和释放线程资源。

       生命治疗仪创建与测试完整代码如下，可验证生命恢复功能和暂停与恢复。

       UE4中的FRunnable与FRunnableThread提供创建常驻型任务所需接口。无论是常驻型还是非常驻型，底层实现相同，都是使用FRunnableThread线程。

       FRunnableThread线程结构包含标识符、逻辑功能、效率与性能、辅助调试字段。线程创建与生命周期分为创建FRunnable类对象、创建FRunnableThread对象两步，通过FRunnable的生命周期管理实现线程运行与停止。

       UE4线程管理流程包括继承并创建FRunnable类对象、创建FRunnableThread对象，生命治疗仪线程创建代码。

       UE4中的几种异步方式底层使用线程实现，学习了线程类型、创建、生命周期、销毁方法，为下篇学习引擎特殊线程打下基础。

python协程（4）：asyncio

        asyncio是官方提供的协程的类库，从python3.4开始支持该模块

        async & awiat是python3.5中引入的关键字，使用async关键字可以将一个函数定义为协程函数，使用awiat关键字可以在遇到IO的时候挂起当前协程（也就是任务），去执行其他协程。

        await + 可等待的对象（协程对象、Future对象、Task对象 -> IO等待）

        注意：在python3.4中是通过asyncio装饰器定义协程，在python3.8中已经移除了asyncio装饰器。

        事件循环，可以把他当做是一个while循环，这个while循环在周期性的运行并执行一些协程（任务），在特定条件下终止循环。

        loop = asyncio.get_event_loop()：生成一个事件循环

        loop.run_until_complete(任务)：将任务放到事件循环

        Tasks用于并发调度协程，通过asyncio.create_task(协程对象)的方式创建Task对象，这样可以让协程加入事件循环中等待被调度执行。除了使用 asyncio.create_task() 函数以外，还可以用低层级的 loop.create_task() 或 ensure_future() 函数。不建议手动实例化 Task 对象。

        本质上是将协程对象封装成task对象，并将协程立即加入事件循环，同时追踪协程的状态。

        注意：asyncio.create_task() 函数在 Python 3.7 中被加入。在 Python 3.7 之前，可以改用 asyncio.ensure_future() 函数。

        下面结合async & awiat、事件循环和Task看一个示例

        示例一：

        *注意：python 3.7以后增加了asyncio.run（协程对象），效果等同于loop = asyncio.get_event_loop()，loop.run_until_complete(协程对象)

*

        示例二：

        注意：asyncio.wait 源码内部会对列表中的每个协程执行ensure_future从而封装为Task对象，所以在和wait配合使用时task_list的值为[func(),func()] 也是可以的。

        示例三：

Spring的@EnableAsync与@Async使用详解

       @EnableAsync注解允许Spring启动异步方法执行，类似于XML配置方式。当与@Configuration结合使用时，整个Spring环境将启用基于注解的异步处理。

       异步方法执行默认使用关联的线程池。若无匹配bean，Spring将使用SimpleAsyncTaskExecutor，它为每个新任务创建新线程。若异步方法返回值为void，调用过程中的异常信息无法返回给调用者，通常仅记录日志。

       自定义线程池和异常处理需实现AsyncConfigurer接口。若仅自定义一个，另一个可直接返回null，Spring将使用默认设置。使用AsyncConfigurerSupport扩展接口，可以全面配置。注意，当ThreadPoolTaskExecutor未被Spring管理时，可添加@Bean注解使其成为管理Bean。加入容器后，无需手动调用initialize方法，它在Bean初始化时自动执行。

       XML配置与基于javaconfig的示例功能等效，除了给Executor添加线程名字前缀。javaconfig方式提供更全面的配置。@EnableAsync注解的mode()属性控制切面应用：默认AdviceMode.PROXY，其他属性共同控制代理方式；若设置AdviceMode.ASPECTJ，则proxyTargetClass属性被忽略，此时需要spring-aspects相关模块的jar包，并且方法内部调用也会被拦截。

       @Async标注用于标记异步执行的方法，可加在方法或类上。加在类上表示类中所有方法均为异步执行。目标方法参数任意，返回值只能为void或Future，可以是ListenableFuture或CompletableFuture，以便更好地与异步任务交互。非future类型的返回值无法获取。

       探究EnableAsync源码，了解其内部工作流程。关注ProxyAsyncConfiguration配置类，它在PROXY模式下由Spring注入。分析AsyncAnnotationBeanPostProcessor，了解Executor和ExceptionHandler的配置过程。异步方法执行通过AnnotationAsyncExecutionInterceptor拦截器实现，最终在AsyncExecutionAspectSupport类中确定使用的Executor。

       详细实现步骤和测试代码可在GitHub上的相应仓库中找到。欢迎扫码关注以获取更多资源和信息。