为什么scala actor消息队列没有界限（大小）
def append(msg: Msg, session: OutputChannel[Any]) {
changeSize(1) // size always increases by 1
val el = new MQueueElement(msg, session)
if (isEmpty) first = el
else last.next = el
last = el
}
MQueue（actor的消息队列）的append方法没有最大大小。这不会导致内存不足吗？
并研究一下changeSize(1)
private var _size = 0
def size = _size
final def isEmpty = last eq null
protected def changeSize(diff: Int) {
_size += diff
}
为什么没有带有private var _size的@volatile？
如果追加时间超过 Int.maxValue 怎么办？
我们是否只是期望这些永远不会发生？
def append(msg: Msg, session: OutputChannel[Any]) {
changeSize(1) // size always increases by 1
val el = new MQueueElement(msg, session)
if (isEmpty) first = el
else last.next = el
last = el
}
the append method of the MQueue(message queue of the actor) have no maximum size. Won't this cause outOfMemory?
And look into the changeSize(1)
private var _size = 0
def size = _size
final def isEmpty = last eq null
protected def changeSize(diff: Int) {
_size += diff
}
why no @volatile with private var _size ?
what if append times exceed the Int.maxValue?
do we just expect those will never happend?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于问题的第一部分：是的，另请参阅此相关问题演员邮箱溢出。 Scala
我认为 _size 变量没有标记为易失性，因为这里期望调用方法负责同步。我简单地浏览了代码，调用此方法的 actor 库的各个部分确实被标记为同步。
对于整数溢出：我想确实预计这种情况永远不会发生。
最常用的 actor 库是 Akka，它确实支持有界邮箱，请参阅 此链接了解语义和配置。除此之外，它们将替换/与 scala 发行版中的 actor 库合并： 正如最近讨论的邮件列表。
For the first part of your question: yes, see also this related question Actors Mailbox Overflow. Scala
I think the _size variable is not marked as volatile because it is expected here that the calling method take care of the synchronization. I briefly scanned through the code and various parts of the actor library that call this method are indeed marked as synchronized.
For the integer overflow: I guess it is indeed expected that this will never happen.
The actor library that is most used is Akka, which does have support for bounded mailboxes, see this link for semantics and configuration. Apart from that they will replace/be merged with the actors library in the scala distribution: as discussed recently on the mailing list.