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

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 {}。
• 僅通過消息與演員進行通信。
• 喜歡不可變的消息。
• 使消息自成一體。