scala - 为什么我应该使用 context.become() 来存储 Actor 的内部状态？

Question

我已阅读 scala-best-practices并有一个关于“5.2. 应该只使用 context.become 改变 actor 中的状态”的问题。我不明白为什么使用 var 存储内部状态如此糟糕.如果 Actor 按顺序执行所有消息，我就看不到任何问题的根源。我想念什么？

Answer 1

考虑 article 中的第一个例子你引用的:

class MyActor extends Actor {
  val isInSet = mutable.Set.empty[String]

  def receive = {
    case Add(key) =>
      isInSet += key

    case Contains(key) =>
      sender() ! isInSet(key)
  }
}

这个例子没有什么本质上不正确的地方，所以没有你遗漏的一些重要的理解。如您所知，参与者按顺序处理其邮箱中的消息，因此只要参与者不公开该状态，就可以安全地在内部变量中表示其状态并改变该状态。
become通常用于动态切换参与者的行为(例如，更改参与者处理的消息类型)和/或其状态。在文章的第二个示例中，actor 的状态在其行为中被编码为参数。这是第一个示例的优雅替代方案，但在这个简单的情况下，这是一个偏好问题。

一种场景，其中 become然而，真正能发光的是具有许多状态转换的actor。不使用 become ， Actor 的逻辑在其 receive块可以变得无法控制的大或变成 if-else 的丛林声明。作为使用 become 的示例要模拟状态转换，请查看此 sample project模拟 "Dining Philosophers"问题。

1一个潜在的问题是，虽然 isInSet是 val ，这是一个可变的 Set ，所以如果 actor 将此状态暴露给 actor 本身之外的某些东西(在示例中它没有这样做)，就会发生奇怪的事情。例如，如果 Actor 发送此 Set在发送给另一个参与者的消息中，外部参与者可以更改此状态，从而导致意外行为或竞争条件。可以通过更改 val 来缓解这一问题。到 var ，并将可变 Set 设置为不可变 Set .