斯卡拉演员 – 最差的做法？

我对使用Scala中的演员感到有些不安。 我已阅读关于如何做的东西的文档，但我想我也需要一些不要规则，以便随意使用它们。 我想我恐怕会以错误的方式使用它们，而我也不会注意到它。

你能想到一些东西，如果应用了，会导致Scala演员带来的好处，甚至是错误的结果？

Answer 1

• 避免!? 只要有可能。 你会得到一个locking的系统！

• 始终从一个Actor子系统线程发送消息。 如果这意味着通过Actor.actor方法创build一个瞬态Actor，那么就是这样：

  case ButtonClicked(src) => Actor.actor { controller ! SaveTrade(trdFld.text) }

• 添加一个“任何其他消息”的处理程序给你的演员的反应。 否则就不可能弄清楚你是否向错误的演员发送了一条消息：

  case other => log.warning(this + " has received unexpected message " + other

• 不要使用Actor.actor作为主angular色，而是使用sublcass Actor 。 原因是只有通过子类才能提供一个合理的toString方法。 再一次，如果你的日志里散布着像下面这样的语句，那么debuggingactor是很困难的：

  12:03 [INFO] Sending RequestTrades(2009-10-12) to scala.actors.Actor$anonfun$1

• logging系统中的angular色，明确说明他们将收到什么消息，以及他们应该如何计算响应。 使用参与者会导致标准过程（通常封装在方法中）的转换，从而变成跨多个参与者的反应的逻辑分布。 没有良好的文档很容易迷路。

• 一定要确保你可以在react循环之外与你的演员进行交stream，以find它的状态。 例如，我总是通过一个MBean声明一个方法来调用它，如下面的代码片段。 否则可能很难判断你的演员是否在运行，closures，是否有大量的消息等等。

。

 def reportState = { val _this = this synchronized { val msg = "%s Received request to report state with %d items in mailbox".format( _this, mailboxSize) log.info(msg) } Actor.actor { _this ! ReportState } } 

• 将你的演员连接在一起，并使用trapExit = true – 否则他们可能会失败默默地意味着你的程序没有做你认为的事情，当消息留在演员的邮箱里时，可能会消失。

• 我认为在这里和这里强调了围绕使用演员做出的devise决定的其他一些有趣的select

Answer 2

我知道这并不能真正回答这个问题，但至less应该重视基于消息的并发性比基于共享内存线程的并发性更不易发生错误的事实。

我认为你已经看到了斯卡拉编程中的演员指导，但logging：

• 演员不应该在处理消息时阻塞。 您可能想要阻止的地方尽量安排稍后收到消息。
• 尽可能使用react {}而不是receive {} 。
• 只通过消息与演员沟通。
• 喜欢不可变的消息。
• 使消息自成一体。