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

Question

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

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

Answer 1

• 避免!?尽可能。你将得到一个锁定的系统！

• 总是从一个Actor子系统线程发送消息。如果这意味着创建通过Actor.actor方法的瞬态演员那就这样吧：

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

• 添加“其他信息”处理你的演员的反应。否则，就不可能搞清楚，如果你要发送消息到错误演员：

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

• 不要为你的主要参与者，sublcass Actor改用Actor.actor。原因在于，只有通过子类别，才能提供合理的方法toString。再次，调试演员是非常困难的，如果你的日志中包含的语句充斥：

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

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

• 务必确保您可以与您的演员沟通，以便在其react循环之外找到其状态。例如，我总是通过一个MBean声明一个方法来调用，它看起来像下面的代码片段。否则可能很难判断你的演员是否在运行，已经关闭，是否有大量的消息等。

。

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 - 否则他们可能会失败默默意味着你的程序是不是做你认为是，将可能走出内存邮件保留在演员的邮箱。

• 我认为，围绕设计，决定利用者进行了其他一些有趣的选择已经凸显here和here

Answer 2

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

我想您已经在斯卡拉编程看到演员的准则，但备案：在处理消息

• 演员不应该阻止。您可能想阻止的地方尽量安排稍后收到消息。
• 尽可能使用react {}而不是receive {}。
• 仅通过消息与演员进行通信。
• 喜欢不可变的消息。
• 使消息自成一体。