皮皮网

1.Vue3之事件循环、异步源码异步nextTick与源码解析
2.功能更新生成源码异步下载，代码让系统响应速度提升10倍
3.Vert.x 源码解析(4.x)——Future源码解析
4.UE4源码剖析——异步与并行 中篇 之 Thread
5.Vert.x 源码解析(4.x)——Context源码解析
6.研发必会-异步编程利器之CompletableFuture(含源码 中)

Vue3之事件循环、异步源码异步nextTick与源码解析

       事件循环是代码JavaScript单线程执行的核心机制，确保了同步任务与异步任务能有序执行。异步源码异步同步任务按顺序执行，代码横盘选股指标源码而异步任务则分为宏任务和微任务。异步源码异步宏任务包括setTimeout、代码setInterval、异步源码异步整体代码、代码ajax、异步源码异步postMessage、代码交互事件等，异步源码异步微任务则包括Promise.then、代码catch、异步源码异步finally、MutationObserver、process.nextTick(Node环境下)。

       事件循环机制确保了同步任务先执行，宏任务和微任务则交替执行，形成事件循环的周期。此过程确保了JavaScript代码的流畅执行，避免了因耗时任务阻塞主线程导致的卡顿。

       在Vue3中，nextTick功能用于处理异步更新DOM问题。它允许开发者在DOM更新之前执行异步代码，确保DOM的正确渲染。有以下两种使用方式：一种是直接传入回调函数，另一种是通过async和await实现。当对数据进行操作后，如果观察到DOM没有更新，原因在于Vue3中数据响应式是同步的，而DOM更新是异步的。

       为解决此问题，可以使用nextTick将同步代码转化为异步代码，确保在浏览器的下一次事件循环中执行DOM更新。在Vue3源代码中，nextTick通过将同步代码包装为Promise，从而转化为异步任务来实现这一功能。

       Vue3将DOM更新设置为异步，旨在优化性能。考虑到大量数据变化时，频繁的DOM更新可能导致性能开销过大，异步更新策略降低了这种浪费，提高了应用的响应性和性能效率。

功能更新生成源码异步下载，让系统响应速度提升倍

       通过本次优化更新，系统在生成源码、流程执行轨迹展示、SQL修改提示、系统函数的jar包定义、运维API依赖JAR包的引入、以及定时任务jar包的管理上，采用了异步操作模式，显著提升了系统响应速度与性能。下面详细解读各项功能的优化点和操作流程。

       1. 生成源码异步下载优化

       优化后，生成源码时将采用异步下载策略。操作流程如下：

       点击项目卡片的赚钱网站源码“设置按钮”并选择“生成源码”。

       在弹出的二次提示框中，选择是否携带JAR包，确认后点击“确定”。

       再次点击项目卡片上的“设置按钮”进入“源码记录”。

       在源码记录列表中可实时查看生成状态，生成完成后即可下载源码包。

       若生成失败，点击操作栏的“详情”按钮查看具体原因。

       2. 流程执行轨迹变量展示优化

       优化后的流程执行轨迹功能，不仅能显示当前组件信息，还支持查看流程中其他组件的详细信息。系统变量信息被分类为入口参数、局部变量、配置组参数和基础参数，便于用户快速了解组件执行结果和变量值。

       3. 修改SQL使用提示优化

       当SQL信息被接口引用时，修改SQL后系统将弹出提示，要求在接口中重新选择该SQL信息后才能生效。删除SQL时，系统会提示已引用的接口，需先去除引用后才能执行删除操作。

       4. 系统函数jar包定义为扩展jar包优化

       系统将一些常用函数定义为扩展jar包，仅在需要时自动加载，减少执行引擎包体积，提升性能。以“SysFun_Feidai_BaseUtilsBaseUtils”为例，进行加载与使用。

       5. 运维API依赖JAR包引入优化

       监控检测扩展jar包在本地客户端和执行引擎中使用时，需下载并安装后才能进行指标监控。操作包括下载、解压、配置，以及启动本地客户端等步骤。

       6. 定时任务jar包定义优化

       定时任务jar包已整合至扩展jar包中，新增定时任务时系统会自动加载。用户也可提前手动添加，确保定时任务与项目部署包一同打包。

       通过这些优化，系统响应速度得到显著提升，操作流程更加高效便捷。有兴趣的用户可申请免费试用体验。

       SoFlu软件机器人，作为全球首款针对微服务架构的软件机器人，革新了传统编码作业模式，通过可视化拖拽与参数配置实现复杂业务逻辑，一人全栈解决后端、前端、测试、运维等各类工作需求，大幅度降低软件开发门槛，显著提升企业软件开发效率与生产力。

       通过引入自动化、标准化与工具化流程，SoFlu软件机器人解决了传统软件开发过程中的依赖人工、成本高昂、技术选型难等问题，突破了被国外开发工具“卡脖子”的技术壁垒，为企业软件开发带来了十倍效率提升。k线指标源码

Vert.x 源码解析(4.x)——Future源码解析

       在现代软件开发中，异步编程的重要性日益凸显，提升并发性能并处理大量并行操作。Vert.x，作为一款基于事件驱动和非阻塞设计的异步框架，提供了丰富的工具简化异步编程。本文将深入解析Vert.x 4.x版本的Future源码，理解其关键类和功能。

       1. 异步核心

       Vert.x的核心在于FutureImpl和PromiseImpl，它们是实现异步操作的关键。AsyncResult是通用接口，用于表示异步操作的结果，包含成功值或失败异常。

       2. Future类详解

       Future扩展了AsyncResult，提供了组合操作如join、any、all和map等功能。内部的FutureInternal主要负责添加监听器，FutureBase负责执行监听器和转换函数。

       具体来说，FutureImpl的onComplete方法接收一个handler，任务完成后执行，而tryComplete则在异步操作有结果时触发，最终调用用户指定的handler。

       相比之下，Promise允许用户手动设置异步结果，PromiseImpl继承自FutureImpl，并增加了context获取功能。

       3. 实例与源码分析

       通过简单的入门实例，如独立使用Future，我们可以看到Vert.x如何通过创建PromiseImpl获取Future。源码分析显示，Promise.future获取Future，OnComplete用于添加监听，而complete方法则用于设置值并通知监听器。

       4. 深入源码

       在源码层面，addListener和emitSuccess方法在OnComplete中扮演重要角色。而complete方法，特别是tryComplete，是设置值并触发监听的关键。

       5. 总结

       总的来说，理解Vert.x中的Future，就是创建PromiseImpl获取Future，通过OnComplete添加监听器，然后通过Promise的complete方法设置值并通知监听器。后续还将深入探讨其他Future实现类，如all、any和map的原理。

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

Vert.x 源码解析(4.x)——Context源码解析

       Vert.x 4.x 源码深度解析：Context核心概念详解

       Vert.x 通过Context这一核心机制，解决了多线程环境下的资源管理和状态维护难题。Context在异步编程中扮演着协调者角色，确保线程安全的资源访问和有序的异步操作。本文将深入剖析Context的源码结构，包括其接口设计、关键实现以及在Vert.x中的具体应用。

       Context源代码解析

       Context接口定义了基础的事件处理功能，如立即执行和阻塞任务。ContextInternal扩展了Context，包含内部方法和功能，通常开发者无需直接接触，如获取当前线程的Context。在vertx的beginDispatch和endDispatch方法中，Context的切换策略取决于线程类型，Vertx线程会使用上下文切换，而非Vertx线程则依赖ThreadLocal。

       ContextBase是ContextInternal的实现类，负责执行耗时任务，内部包含TaskQueue来管理任务顺序。WorkerContext和EventLoopContext分别对应工作线程和EventLoop线程的执行策略，它们通过execute()、runOnContext()和emit()方法处理任务，同时监控性能。

       Context的创建和获取贯穿于Vert.x的生命周期，它在DeploymentManager的doDeploy方法中被调用，如NetServer和NetClient等组件的底层实现也依赖于Context来处理网络通信。

       额外说明

       Context与线程并非直接绑定，而是根据场景动态管理。部署时创建新Context，非部署时优先获取Thread和ThreadLocal中的Context。当执行异步任务时，当前线程的Context会被暂时替换，任务完成后才恢复。源码中已加入详细注释，如需获取完整注释版本，可联系作者。

       Context的重要性在于其在Vert.x的各个层面如服务器部署、EventBus通信中不可或缺，它负责维护线程同步与异步任务的执行顺序，是异步编程中不可或缺的基石。理解Context的实现，有助于更好地利用Vert.x进行高效开发。

研发必会-异步编程利器之CompletableFuture(含源码 中)

       微信公众号访问地址： 研发必会-异步编程利器之CompletableFuture(含源码 中)

       近期热推文章：

       1、springBoot对接kafka,批量、并发、异步获取消息,并动态、批量插入库表;

       2、SpringBoot用线程池ThreadPoolTaskExecutor异步处理百万级数据;

       3、基于Redis的Geo实现附近商铺搜索(含源码)

       4、基于Redis实现关注、取关、共同关注及消息推送(含源码)

       5、SpringBoot整合多数据源，并支持动态新增与切换（详细教程）

       6、基于Redis实现点赞及排行榜功能

       7、研发必会-异步编程利器之CompletableFuture(上)

       一、多任务组合回调

       备注：源码获取方式在文底。

       1.1、AND组合关系

       thenCombine / thenAcceptBoth / runAfterBoth都表示：将两个CompletableFuture组合起来，只有这两个都正常执行完了，才会执行某个任务。也即：当任务一和任务二都完成再执行任务三(异步任务)。

       区别在于：

       1、runAfterBoth：不会把执行结果当做方法入参，且没有返回值。

       2、thenAcceptBoth：会将两个任务的执行结果作为方法入参，传递到指定方法中，且无返回值。

       3、thenCombine：会将两个任务的执行结果作为方法入参，传递到指定方法中，且有返回值。

       代码案例：

       运行结果：

       1.2、OR组合关系

       将两个CompletableFuture组合起来，只要其中一个执行完了，就会执行某个任务。（两个任务，只要有一个任务完成，就执行任务三）

       区别在于：

       1、runAfterEither：不会把执行结果当做方法入参，且没有返回值。

       2、acceptEither: 会将已经执行完成的任务，作为方法入参，传递到指定方法中，且无返回值。

       3、applyToEither：会将已经执行完成的任务，作为方法入参，传递到指定方法中，且有返回值。(个人推荐)

       参考代码：

       返回结果：

       若将异步任务中的Thread.sleep()改为，将输出的结果为：

       从结果中不难对比发现，任务的参数是任务和任务中执行最快的返回结果。

       注意：若把核心线程数量改为1，会是什么样的呢？

       运行结果：

       从上面看出，改为1就变成单线程执行了。

       1.3、多任务组合(allOf\anyOf)

       1.allOf：等待所有任务都执行完成后，才会执行 allOf 返回的CompletableFuture。如果任意一个任务异常，allOf的CompletableFuture，执行get方法，会抛出异常。(等待所有任务完成才会执行)

       2.anyOf:任意一个任务执行完，就执行anyOf返回的CompletableFuture。如果执行的任务异常，anyOf的CompletableFuture，执行get方法，会抛出异常。(只要有一个任务完成)

       参考案例：

       结果返回：

       从结果中看出：等待所有任务都执行完成后，才会执行 allOf 返回的CompletableFuture。

       同理anyOf，只需要调整代码：

       运行结果：

       1.4、thenCompose

       thenCompose方法会在某个任务执行完成后，将该任务的执行结果，作为方法入参，去执行指定的方法。该方法会返回一个新的CompletableFuture实例。

       1、如果该CompletableFuture实例的result不为null，则返回一个基于该result新的CompletableFuture实例；

       2、如果该CompletableFuture实例为null，然后就执行这个新任务。

       代码案例：

       结果：

       二、使用注意点

       CompletableFuture 使异步编程更加便利的、代码更加优雅的同时，也要关注使用的一些注意点。

       2.1、Future需要获取返回值，才能获取异常信息

       代码案例：

       输出结果：

       Future需要获取返回值(res.get())，才能获取到异常信息。如果不加 get()/join()方法，看不到异常信息。使用的时候，注意一下，考虑是否加try…catch…或者使用exceptionally方法。

       若改成exceptionally方法，无需get或join也可以捕获异常信息：

       结果：

       2.2、CompletableFuture的get()方法是阻塞的

       CompletableFuture的get()方法是阻塞的，如果使用它来获取异步调用的返回值，需要添加超时时间。

       推荐使用：

       2.3、建议使用自定义线程池，不要使用默认的

       CompletableFuture代码中使用了默认的线程池，处理的线程个数是电脑CPU核数-1。在大量请求过来的时候，处理逻辑复杂的话，响应会很慢。一般建议使用自定义线程池，优化线程池配置参数。

       参考案例：

       但是如果线程池拒绝策略是DiscardPolicy或者DiscardOldestPolicy，当线程池饱和时，会直接丢弃任务，不会抛弃异常。因此建议，CompletableFuture线程池策略最好使用AbortPolicy，然后耗时的异步线程，做好线程池隔离。

       说明：

       AbortPolicy（默认）：直接抛弃

       CallerRunsPolicy：用调用者的线程执行任务

       DiscardOldestPolicy：抛弃队列中最久的任务

       DiscardPolicy：抛弃当前任务。

       三、源码获取方式

       更多优秀文章，请关注个人微信公众号或搜索“程序猿小杨”查阅。然后回复：源码，可以获取对应的源码，开箱即可使用。

       如果大家对相关文章感兴趣，可以关注微信公众号"程序猿小杨"，会持续更新优秀文章!欢迎大家 分享、收藏、点赞、在看，您的支持就是我坚持下去的最大动力！谢谢!

       参考网站：

       blog.csdn.net/ThinkWon/...

       mp.weixin.qq.com/s/shjA...

Rust Async: smol源码分析-Executor篇

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

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

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

vue2.x中的数据异步更新和nextTick方法解析

       前言

       众所周知，vue中的更新时异步的，比如this.msg=xxx，你看起来他是立马更新了，其实并没有。它会异步执行，接下来就来看看怎么实现的吧。

先上图首先从数据改动开始说起

       调用this.msg=xxx数据发生变更

       在数据初始化阶段已经收集了依赖的watcher到dep中，执行dep.notify通知watcehr变更

       notify方法遍历调用所有以来的watcher的update方法，把当前watcher实例放入queueWatcher函数中执行，接下来就是异步更新的关键了，看代码

       queueWatcher函数代码在src\core\observer\scheduler.js主要作用：把当前watcher实例添加到一个queue中

exportfunctionqueueWatcher(watcher:Watcher){ //拿到watcher的唯一标识constid=watcher.id//无论有多少数据更新，相同的watcher只被压入一次//我理解这就是为什么在一次操作中，多次更改了变量的值，但是只进行了一次页面更新的原因，//同一变量依赖它的watcher是一定的，所以已经存在了就不再放进watcher队列中了，也不会走后面的逻辑if(has[id]==null){ //缓存当前的watcher的标识,用于判断是否重复has[id]=true//如果当前不是刷新状态,直接入队if(!flushing){ queue.push(watcher)}else{ //ifalreadyflushing,splicethewatcherbasedonitsid//ifalreadypastitsid,itwillberunnextimmediately.//此处能走到这儿，说明flushSchedulerQueue函数被执行了watcher队列已经正在开始被更新了,//并且在执行某个watcher.run方法的时候又触发的数据响应式更新，重新触发了queueWatcher//因为在执行的时候回有一个给watcher排序的操作，所以，当watcher正在更新时已经是排好顺序了的，此时需要插入到特定的位置，保持watcher队列依然是保持顺序的leti=queue.length-1while(i>index&&queue[i].id>watcher.id){ i--}queue.splice(i+1,0,watcher)}//queuetheflush//waiting表示当前的flushSchedulerQueue还没有被执行，因为还没有重置状态，waiting仍然为true//所以waiting的意义就是表明是否执行了flushSchedulerQueue,if(!waiting){ waiting=true//直接同步刷新队列if(process.env.NODE_ENV!=='production'&&!config.async){ //同步执行flushSchedulerQueue()return}//把更新队列函数放到异步队列中nextTick(flushSchedulerQueue)}}}

       flushSchedulerQueue代码在相同目录下//主要作用:遍历执行每一个watcher的run方法，进而实现数据和视图的更新，并在执行完所有的方法之后，重置状态，表示正在刷新队列的flushing，表示watcher是否存在的has，表示是否需要执行nexttick的waiting

functionflushSchedulerQueue(){ //当方法被执行时，设置为正在刷新状态，以示可以继续执行nextTick方法flushing=true//把队列中的watcher排个序，/***排序的作用：（此句照搬照抄而来）*1.保证父组件的watcher比子组件的watcher先更新，因为父组件总是先被创建，子组件后被创建*2.组件用户的watcher在其渲染watcher之前执行。*3.如果一个组件在其父组件执行期间被销毁了，会跳过该子组件。*/queue.sort((a,b)=>a.id-b.id)//中间略去若干代码...//遍历queue中存的所有的watcher，执行run方法更新for(index=0;index<queue.length;index++){ watcher=queue[index]watcher.run()}//因为queue是在一个闭包中，所以当遍历执行完毕了，就把队列清空queue.length=0;//has是判断当前watcher是否重复，作为是否把watcher放进queue的依据//此时已经执行完了queue中的所有watcher了，之前已经执行过的watcher如果发生了变更，可以重新加入了has={ }//waiting是判断是否执行nextTick的标识，当前的刷新队列已经执行完毕了，说以，可以设置为false了，执行下一轮的的添加异步事件队列的方法//flushing是判断是否当前异步事件正在执行的标志，当前更新完毕，作为判断watcher入队的形式waiting=flushing=false}

       nextTick方法源码src\core\util\next-tick.js

exportfunctionnextTick(cb?:Function,ctx?:Object){ let_resolve//把执行更新操作之后的回调函数添加到队列里//用trycatch包装一下传进来的函数，避免使用$nextTick时，传入的回调函数出错能够及时的捕获到//只要执行了nextTick函数，就把回调函数添加到回调列表里//这里的cb回调函数就是flushSchedulerQueue函数，里面执行了queue中存放的所有的watcher.run方法callbacks.push(()=>{ if(cb){ try{ cb.call(ctx)}catch(e){ handleError(e,ctx,'nextTick')}}elseif(_resolve){ _resolve(ctx)}})//通过pending来判断是否需要向任务队列中添加任务//如果上一个清空回调列表的当flushCallbacks函数还在任务队列中，就不往任务队列中添加//第一次执行时，就默认就添加一个进任务队列，一旦添加进任务队列，就表明暂时不在需要往任务队列中添加flush函数//当执行了上一个flushCallbacks函数的时候，pending修改为false，表明可以重新添加一个清空回调列表的flush函数到任务队列了if(!pending){ pending=true//这里是调用清空callbacks数组中方法，并执行的函数，timerFunc()}//$flow-disable-line//判断当前环境是否支持promise，如果支持的话，可以返回一个期约对象，if(!cb&&typeofPromise!=='undefined'){ returnnewPromise(resolve=>{ _resolve=resolve})}}

       timerFunc()方法，主要是做一些降级操作，实现异步的关键

timerFunc=()=>{ Promise.resolve().then(flushCallbacks)}//如果当前环境不支持的话，会进行一定的降级操作，直到最后，用宏任务settimeout来处理

       看看flushCallbacks,任务就是执行了所有的callbacks函数

functionflushCallbacks(){ //如果开始执行了flushCallbacks说明，当前的异步任务已经为空了，如果此时再nextTick方法会添加新的任务进去了pending=false//拷贝一份callbacks中的所有回调函数，用于执行constcopies=callbacks.slice(0)//随即删除所有callbackscallbacks.length=0//当微任务队列中的flushCallbacks添加到执行栈中了，就执行callbacks中的所有的函数//也就是调用执行每一个flushSchedulerQueue函数，然后遍历执行每一个函数for(leti=0;i<copies.length;i++){ copies[i]()}}基本关键变量的作用

       waiting：变量，作为是否执行nextTick，添加flushSchedulerQueue方法的关键，标志着callbacks中是否有flushSchedulerQueue方法,比如同一个变量的改变，可能会影响多个watcher，因为执行flushSchedulerQueue是异步的，遍历dep.update先把所有的watcher都放入到queue中，也才只执行了一次nextTick，callbacks中也只有一个方法。虽然当第一次方如watcher时就会执行nexttick把flushSchedulerQueue方法放入callbacks中，看起来好像已经要执行了，但是因为queue是闭包变量，所以，后续的变量仍然可以添加queue中，

       flushing：:表示是否正在执行flushSchedulerQueue方法，如果是正在执行更新方法的话，对向已经排好序的watcher队列中添加新的watcher，需要把新watcher插入到排好序的指定的位置，这也就是为什么遍历watdher那块儿会直接使用queue.length的原因，这个长度会发生变化。

       pending：:pending是决定是否把更新callbacks数组的方法放入异步队列的关键，保证了异步队列中只有一个清空callbacks的任务,也就解释了，连续手动执行多个$nextTick方法不会立即执行，也还是会把他们的回调放入callbacks中，然后等到任务都执行完毕了，一下把所有的回调函数都执行掉。

       参考

       vue源码

       /post/