Spring 状态机 - 我应该创建多少？

Question

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

我已经阅读了文档并使用了它，但有些事情让我望而却步：

1. 请求和状态机之间是否应该存在一对一的关系，这意味着对于每个请求，我都会创建一个新的状态机实例？或者我应该通过为下一个请求重置机器来以某种方式重用已完成的状态机？

2. 完成状态机的清理怎么样？似乎没有办法销毁和清理状态机实例。如果我为每个请求创建 1 个，我实际上已经引入了内存泄漏，除非框架以某种方式处理资源。

Answer 1

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

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