Spring State Machine - 我应该创建多少？答案

【问题标题】：Spring State Machine - How many should I create?Spring State Machine - 我应该创建多少？
【发布时间】：2016-12-29 06:21:23
【问题描述】：

当我收到关于我的 API 的请求时，我想要执行一系列步骤，每个步骤都是检查或扩充。每一步都可能成功或失败。成功后，应执行下一步。失败时，应执行结束步骤，并完成流程。为此，我考虑了 Spring State Machine，因为它似乎符合要求。

我已经阅读了文档并使用了它，但有些事情让我无法理解：

请求和状态机之间是否应该存在一对一的关系，这意味着对于每个请求，我都会创建一个新的状态机实例？或者我应该通过为下一个请求重置机器来以某种方式重用已完成的状态机？
如何清理已完成的状态机？似乎没有办法销毁和清理状态机实例。如果我为每个请求创建 1 个，则实际上引入了内存泄漏，除非框架以某种方式处理资源。

【问题讨论】：

我不熟悉 spring 的实现，但查看文档表明每台机器都有其状态的内部表示（与存储在机器外部的状态相比；ala State currentState = machine.start()） .这将排除在多个请求中使用单个机器，因为第二个请求可能在第一个请求完成之前发生 - 可能会导致一些奇怪的行为。
话虽如此；状态机有必要吗？如果您只是检查是否满足先决条件；一个简单的if (!firstSuccess) return failure; if (!secondSuccess) return failure; 还不够吗？
我认为有几种设计可以支持这种流程。其中之一是 SSM。所以为了尝试，我选择了它。我同意你的观点，请求和状态机实例之间必须是一对一的。但这留下了资源控制的问题。是否应该回收实例？还是应该丢弃它们？如果有，怎么做？
它们有可能被回收吗？看着here，我看不到任何暗示可以重新启动 SM 的东西，尽管 start 函数并没有表明它不能被调用两次 - 所以我不确定。第二;在我看来，维护一个未使用的 SM 池所需的工作量很大——我认为我会丢弃它们，让 GC 处理它。
不过，如果性能很重要，我可能会介绍一下。不确定构建 SM 涉及多少开销，因此创建共享池可能更有效。

【解决方案1】：

您的问题没有绝对正确的答案，所以我只需要在这里留下一些 cmets。状态机作为一个概念非常松散，它为您提供了许多不同的做事方式。

如果一个接一个的步骤与tasks 配方的实施方式有关，则整个概念。它执行一系列任务，如果父任务失败，机器会进入错误状态，让用户有机会修复问题并请求机器继续。 statemachine-recipes-tasks statemachine-examples-tasks。这种用例可能是创建新配方的理想选择，因为它非常通用。
框架应该在机器停止后清除东西，最终 jvm 应该清除垃圾。如果您发现异常，请提交 gh issue，我们会修复问题。
我们有样本statemachine-examples-eventservice，它正在重用机器，但我目前正在重新实现该样本（它可以工作，但应该更好地实现），因为我们的主厨告诉我，我在那里所做的是转储@987654324 @。机器不能与 session 范围一起使用，如果丰富的对象（即 ssm 是）被序列化，事情就会向南。
组合状态和选择来完成您的步骤流程相对容易。唯一的问题是您希望它可重复使用多少（因此通用配方将是一件好事，欢迎 PR :)）
我在gh-240 的状态图中提出的错误处理内容也是需要考虑的。
ssm 是否可以作为更通用的流引擎工作存在一些问题，但它可能永远不会成为这样，因为它将是一个全新的项目。认为大部分流程都可以作为单独的配方处理。

【讨论】：