10

假设我有一些具有 type 属性actor_的类Actor。我这样做有问题吗

def someMethod() = {
  actor_ ! "HELLO"
}

或者是否应该始终从另一个参与者发送消息;例如

def someMethod() = {
  Actor.actor { actor_ ! "HELLO" }
}
4

2 回答 2

8

这取决于。当您从非参与者代码向参与者发送消息时,会自动创建一个 ActorProxy 并将其存储在本地线程中。这会造成潜在的内存泄漏,尽管非常小,因为 ActorProxy 在线程被 GC 之前不会被 GC。ActorProxy 本质上使非actor线程在许多方面表现得像一个Actor,包括接收消息。

更大的问题是,如果您的线程被管理,类似于 actor 库管理线程的方式,那么表示逻辑上下文的内容可能有时在一个线程上,而在另一时间在另一个线程上。一个很好的例子是 servlet 容器。您的逻辑上下文可能是 servlet 或会话,但 ActorProxy 将绑定到线程,因此可以跨逻辑上下文共享。如果您的演员没有回复 ActorProxy 这没什么大不了的,但如果他们是的话,它可能会导致问题,因为(a)回复可能会被错误的上下文接收,或者(b)消息永远不会收到,因此前面提到的小泄漏会随着 ActorProxies 的邮箱被填满而变成大泄漏。

[编辑] 嗯...我似乎在阅读问题时遇到了问题!将它包围在 actor 块中会创建一个新的 actor 对象,该对象在终止时将被正确地 GC。请记住,将消息发送放在参与者块中意味着消息发送将在另一个线程上的新反应中完成,而不是在创建参与者的线程中完成。

于 2009-06-30T11:23:02.320 回答
0

我认为这样做没有问题。如果它在您的代码中有意义,那为什么不呢?如果你看一下纯演员模型,一切都是演员,只有演员相互交流,如果你可以这样设计你的代码..很棒..如果你不能或不想,那么可以发送从非参与者到参与者的消息。

于 2009-06-29T22:39:31.670 回答