代码拉取完成，页面将自动刷新
环境：
（Asynchronous Continuations）
Flowable以事务方式执行流程，并可按照你的需求配置。让我们从Flowable一般如何为事务划分范围开始介绍。如果Flowable被触发（启动流程，完成任务，为执行发送信号），Flowable将沿流程执行，直到到达每个执行路径的等待状态。更具体地说，它以深度优先方式搜索流程图，并在每个执行分支都到达等待状态时返回。等待状态是“之后”再执行的任务，也就是说着Flowable将当前执行持久化，并等待再次触发。触发可以来自外部来源如用户任务或消息接受任务，也可以来自Flowable自身如定时器事件。以下面的图片说明：
这是一个BPMN流程的片段，有一个用户任务、一个服务任务，与一个定时器事件。用户任务的完成操作与验证地址（validate address）在同一个工作单元内，因此需要原子性地（atomically）成功或失败。这意味着如果服务任务抛出了异常，我们会想要回滚当前事务，以便执行返回到用户任务，并希望用户任务仍然保存在数据库中。这也是Flowable的默认行为。在（1）中，应用或客户端线程完成任务。在相同的线程中，Flowable执行服务并继续，直到到达等待状态，在这个例子中，是定时器事件（2）。然后将控制权返回至调用者（3），同时提交事务（如果事务由Flowable开启）。
在有的情况下，我们不想要这样。有时我们需要在流程中自定义地控制事务边界，以便为工作的逻辑单元划分范围。这就需要使用异步延续。考虑下面的流程（片段）：
完成用户任务，生成发票，并将发票发送给客户。这次发票的生成不再是同一个工作单元的一部分，因此我们不希望当发票生成失败时，回滚用户任务。所以我们希望Flowable做的，是完成用户任务（1），提交事务，并将控制权返回给调用程序。然后我们希望在后台线程中，异步地生成发票。这个后台线程就是Flowable作业执行器（事实上是一个线程池），它周期性地将作业保存至数据库。因此在幕后，当到达"generate invoice（生成发票）"任务时，Flowable会创建“消息”作业并将其持久化到数据库中，用于继续执行流程。这个作业之后会被作业执行器选中并执行。Flowable也会向本地的作业执行器进行提示，告知其有新作业到来，以提升性能。
要使用这个特性，可以使用*flowable:async="true"*扩展。因此，一个示例的服务任务会像是这样：
<serviceTask id="service1" name="Generate Invoice"
flowable:class="my.custom.Delegate"
flowable:async="true" />
</serviceTask>
可以为下列BPMN任务类型指定flowable:async：任务，服务任务，脚本任务，业务规则任务，发送任务，接收任务，用户任务，子流程，调用活动。
对于用户任务、接收任务与其他等待状态来说，异步操作允许我们在一个独立的线程/事务中启动执行监听器。
默认配置下，如果作业执行中有任何异常，Flowable将三次重试执行作业。对异步作业也是这样。需要更灵活的配置时可以使用这两个参数：
这两个参数可以通过flowable:failedJobRetryTimeCycle元素配置。这有一个简单的例子：
<serviceTask id="failretryservicetask" name="三次重试执行作业" flowable:async="true" flowable:exclusive="false" flowable:class="com.study.demo.delegate.FailRetryJavaDelegate">
<extensionElements>
<flowable:failedJobRetryTimeCycle>R3/PT2M</flowable:failedJobRetryTimeCycle>
</extensionElements>
</serviceTask>
时间周期表达式与定时器事件表达式一样遵循ISO 8601标准。上面的例子会让作业执行器重试3次，并在每次重试前等待2分钟。
从近期版本开始，JobExecutor确保同一个流程实例的作业永远不会并发执行。为什么这样？
考虑下面的流程定义：
一个并行网关，之后是三个服务任务，都使用异步操作执行。其结果是在数据库中添加了三个作业。当作业储存在数据库后，就由JobExecutor处理。JobExecutor获取作业，并将其委托至工作线程的线程池，由它们实际执行作业。这意味着通过使用异步操作，可以将工作分发至线程池（在集群场景下，甚至会在集群中跨越多个线程池）。通常这都是好事。但也有其固有问题：一致性。考虑服务任务后的并行合并：当服务任务的执行完成时到达并行合并，并需要决定等待其他执行，还是需要继续向前。这意味着，对于每一个到达并行合并的分支，都需要选择继续执行，还是需要等待其他分支上的一个或多个其他执行。
为什么这是问题呢？这是因为服务任务配置为使用异步延续，有可能所有相应的作业都同时被作业执行器处理，并委托至不同的工作线程。结果是服务执行的事务，与到达并行合并的3个独立执行所在的事务会发生重叠。如果这样，每一个独立事务都“看不到”其他事物已经并发地到达了同样的并行合并，并因此判断自己需要等待其他事务。然而，如果每个事务都判断需要等待其他事务，在并行合并后不会有继续流程的事务，而流程实例也就会永远保持这个状态。
Flowable如何解决这个问题呢？Flowable使用乐观锁。每当需要基于数据进行判断，而数据可能不是最新值（因为其他事务可能在我们提交前修改了这个数据）时，我们确保会在每个事务中都增加同一个数据库记录行的版本号。这样，无论哪个事务第一个提交，都将成功，而其他的会抛出乐观锁异常并失败。这样就解决了上面流程中讨论的问题：如果多个执行并发到达并行合并，它们都判断需要等待，增加其父执行（流程实例）的版本号并尝试提交。无论哪个执行第一个提交，都可以成功提交，而其他的将会抛出乐观锁异常并失败。因为这些执行由作业触发，Flowable会在等待给定时间后，重试执行相同的作业，期望这一次通过这个同步的网关。
这是好的解决方案么？我们可以看到乐观锁使Flowable避免不一致状态。它确保了我们不会“在合并网关卡住”，也就是说：要么所有的执行都通过网关，要么数据库中的作业能确保可以重试通过它。然而，尽管这是一个持久化与一致性角度的完美解决方案，但从更高层次看，仍然不一定总是理想行为：
排他作业不能与同一个流程实例中的其他排他作业同时执行。考虑上面展示的流程：如果我们将服务任务都声明为排他的，则JobExecutor将确保相关的作业都不会并发执行。相反，它将确保不论何时从特定流程实例中获取了排他作业，都会从同一个流程实例中获取所有其他的排他作业，并将它们委托至同一个工作线程。这保证了作业的顺序执行。
如何启用这个特性？从近期版本开始，排他作业成为默认配置。所有异步操作与定时器事件都默认为排他的。另外，如果希望作业成为非排他的，可以使用flowable:exclusive="false"配置。例如，下面的服务任务是异步，但非排他的。
<serviceTask id="service" flowable:expression="${myService.performBooking(hotel, dates)}"
flowable:async="true" flowable:exclusive="false" />
</serviceTask>
这是好的解决方案么？有很多人都在问这个问题。他们的顾虑是，这将阻止并行操作，因此会有性能问题。但也需要考虑以下两点：
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。