我有一个系统，它可能会在交易的生命周期中生成某些事件。每一次我都需要更新数据库中的一行，并通过 websocket 发送一个 UI 事件。
我有一个选择是在 Actor 中实现事件处理（DB 和 UI），从而避免任何锁定问题 - 我也可以承受轻微的延迟，因此按顺序处理会大大简化问题。
在 Scala 中处理这个问题的替代方法是什么，因为我觉得在这种情况下 Actors 可能是矫枉过正的？ 有那些博客指出演员应该用于“与状态并发”——尽管我希望看到一个更合适的机制来消除这个选项。
【问题讨论】：
标签： multithreading scala concurrency akka
最终，使用 Actor 的主要独特好处是它们非常适合封装可变变量，从而避免竞争条件。
要按照您的描述进行操作，您可以使用经典线程。在您的（可能是简化的）描述中，我没有看到死锁的可能性。如果你想要一些更可组合的东西，例如一系列异步任务，你可以使用 Scala 的Futures。
【讨论】：
完全不确定这是否适用于 Scala，但是对于 Groovy 和 Java 有一个很棒的库，其中包含多个并发模型。我自己使用Dataflow Concurrency 取得了巨大成功，我可以推荐它作为一个轻量级但易于管理的模型。
Dataflow Concurrency 提供了另一种并发模型，即 本质上是安全和坚固的。它强调数据及其 流过你的流程而不是实际的流程 操纵数据。数据流算法让开发人员从 处理活锁、竞争条件和制造死锁 确定性，因此 100% 可重现。如果你没有遇到死锁 在测试中，您不会在生产环境中使用它们。
链接的GPars 库中还有其他可用的模型。
我不建议自己做线程，除非你别无选择。
附录
发布后，我对该主题感兴趣并进行了一些搜索。似乎也像Akka has direct support for Dataflow model。或者至少在某些版本中有过。
【讨论】：
Actor 避免了锁定问题，因为它们使用队列进行交互。您可以将线程与（阻塞）队列一起使用并获得相同级别的安全性。与线程相比，Actor 的唯一优势是 Actor 不会为调用堆栈消耗内存，因此在相同数量的核心内存中，我们可以拥有比线程多得多的 Actor。 Actor 模型的缺点是可以在单线程中实现的复杂算法需要多个 Actor，因此 Actor 的实现可能看起来很模糊。
【讨论】：