问题标签 [actor]

这是我在这里的第一条消息，我很高兴加入这个社区。

看起来现在一切都在朝着多线程开发方向发展。大鱼说，达到数百个核心不会需要更长的时间。

我最近阅读了有关基于actor的开发以及消息传递是如何处理并发编程的精彩内容。此外，我还读到它们可以作为方法调用的一种手段来实现。在这种情况下，给定的对象也是一个演员。

换句话说，我们不再随意调用方法。他们在队列中发布以进行后期处理。然后，队列确保不会同时修改对象的状态（var），因为消息都是序列化的。

我知道这个模型很容易实现（至少是一个实验模型），也许这就是为什么很难找到任何技术细节的原因。

我的问题涉及队列。这是多个生产者和一个消费者的典型案例，我怀疑他们需要某种同步。真的吗？会有另一种解决方案吗？我听说它们可以实现为无锁结构。

我不太确定。任何评论将不胜感激。

祝朋友们度过愉快的一天

有没有办法监控有多少线程实际上是活动的并运行我的 scala 演员？

什么时候应该使用Actor 模型？

它当然不能保证无死锁的环境。

演员 A 可以等待 B 的消息，而 B 等待 A。

此外，如果参与者必须确保其消息在继续执行下一个任务之前已得到处理，则它必须发送消息并等待“您的消息已处理”消息，而不是直接阻塞。

模型的力量是什么？

在我的演员中，我必须创建一个向另一个演员发送消息的类。另一个演员应该回复演员A

现在的问题是，当从内部类发送时，我不再在演员本身内，因此演员 B 没有得到对演员 B 的正确引用。解决此问题的一种方法是通过传递对 A 的引用消息，但这对我来说似乎很丑陋。

有没有更优雅的方法来解决这个问题？

所以我想写一些看似阻塞的网络代码，而不是真正阻塞一个线程。我将通过网络发送一些数据，并有一个响应“队列”，这些响应将通过网络返回。我写了一个非常简单的概念证明，灵感来自此处的演员教程中的生产者/消费者示例：http ://www.scala-lang.org/node/242

问题是，使用接收似乎占用了一个线程，所以我想知道是否无论如何不占用一个线程并且仍然获得“阻塞感”。这是我的代码示例：

有没有办法在不使用接收的情况下做到这一点，从而使其无线程？

到目前为止，我正在为以下问题苦苦挣扎一周，需要一些建议。

我想构建一个管道，如：

到目前为止，我已经将每个 Pipeline-Segment 实现为一个 Actor。我需要为每个查询创建专用的参与者实例，因为其中一些参与者（如 filterXXX 和合并）需要维护每个查询的状态。

像 askIMDB 这样的函数会产生多个我想同时处理的结果（每个结果都给一个单独的参与者）。所以我没有找到任何方法在执行 query()之前预先构建整个演员图，也没有在运行时修改它的优雅方法。

我的第一次尝试是一个演员链，并在消息中传递诸如事务 ID 之类的东西，所以每个演员都有一个 Map[TransactionID->State] 但这感觉相当难看。第二次尝试是创建一种管道，将参与者的有向图抽象为一个流程，但到目前为止我失败了。

这是我的第一篇文章，如果我忘记了什么或者问题是一般/伪编码，对不起。非常感谢任何建议。谢谢！

我对 Plausible Labs PLActorKit 很感兴趣：

http://code.google.com/p/plactorkit/

但是文档只有单个 Echo 示例。在深入研究之前，我很好奇是否有任何使用 PLActorKit 的开源项目我可以看看。

我只是在学习，并且非常喜欢 Actor 模式。我现在正在使用 Scala，但我对一般的架构风格很感兴趣，因为它用于 Scala、Erlang、Groovy 等。

我正在考虑的情况是我需要同时做一些事情，例如，让我们说“运行一份工作”。

使用线程，我将创建一个线程池和一个阻塞队列，并让每个线程轮询阻塞队列，并在作业进出队列时处理它们。

对于演员，处理这个问题的最佳方法是什么？创建一个演员池并以某种方式向他们发送包含作业或作业的消息是否有意义？也许有一个“协调员”演员？

注意：我忘记提到的案例的一个方面是：如果我想限制我的应用程序将同时处理的作业数量怎么办？也许有配置设置？我在想一个游泳池可能会很容易做到这一点。

谢谢！

我对包含长时间运行的操作的演员有很多麻烦，在我的情况下是持久的套接字连接。下面是一些测试代码，如果我创建的服务器实例少于四个，它运行良好，但是如果我创建更多的实例，我总是最终只有三个或有时四个并发套接字连接，因为其他连接超时。我想知道为什么会这样，以及我的代码是否有明显的问题。

顺便提一句。我正在使用 scala 2.7.6 final。

我有一个应用程序使用了很多演员：准确地说是 25,000。它使用Scala 2.7.7 并在jdk6_u18上运行。它基本上是监听和处理市场数据，状态很少。

它每天早上 8 点 2 点开始，一个小时内就崩溃了OutOfMemoryError。“啊哈”你说，“你有内存泄漏！” 除了当我重新启动它时，它永远不会在一天的剩余时间内再次崩溃！尽管美国市场在下午 2.30 开放时，GC 和 CPU 开销都增加了。

一些轶事发现：

• 它在 Solaris 上运行。当我过去在 Linux 上运行它时，它从来没有崩溃过。
• 我试过搞乱代堆大小，分配更多内存等。我认为这没什么区别
• 当我verbose:gc打开时，收集器的行为似乎有所不同

提出了几个问题：

1. 为什么这个程序的行为在 Linux 和 Solaris 之间会有所不同？
2. 为什么从 8.02 开始和从 8.42 开始的行为会有所不同？
3. 我听说演员库有一些内存泄漏问题。它们是什么，什么时候修复的，我如何发现这里是否发生了“类似”的事情？（在jhat等中寻找的东西）
4. 有谁知道可能会发生什么？

我现在正试图G1看看这是否有什么不同。我明天会更新这个问题！

G1 的一些输出，带有 verbose:gc on

我想我只是在行动中抓住了它：

600.290：[完全 GC 255M->144M(256M)，1.5772616 秒]
602.084：[GC 暂停（年轻）227M->145M(256M)，0.0556769 秒]
602.418：[完全 GC 254M->1441526 秒，1. ]
604.279：[GC 暂停（年轻）227M->145M（256M），0.0415157 秒]
604.602：[完全 GC 255M->145M（256M），1.6041762 秒]
606.422：[GC 暂停（年轻）227M->145M（256 ), 0.0237441 秒]
606.710: [完整 GC 254M->145M(256M), 1.6022185 秒]

然后稍晚一点（你可以看到完整的 GC 花费了更长的时间并且回收的更少）

849.084: [完全 GC 254M->176M(256M), 1.9658754 秒]
851.191: [GC 暂停 (年轻) 228M->176M(256M), 0.0218611 秒]
851.414: [完全 GC 254M->1765257 秒, 1. ]
853.492：[GC 暂停（年轻）228M->176M（256M），0.0224688 秒]
853.716：[完全 GC 254M->176M（256M），1.9339705 秒]
855.793：[GC 暂停（年轻）228M->176M（256 ), 0.0215707 秒]
856.009: [完全 GC 254M->176M(256M), 1.9805797 秒]
858.137: [GC 暂停 (年轻) 228M->176M(256M), 0.0223224 秒]

G1 的一些输出，详细信息：gc 关闭

又好了！*叹*

303.656：[GC 暂停（年轻）225M->93M（256M），0.1680767 秒]
308.060：[GC 暂停（年轻）226M->94M（256M），0.1793724 秒]
312.746：[GC 暂停（年轻）227M->93M (256M), 0.1674851 secs]
316.162: [GC pause (young) 227M->95M(256M), 0.1826145 secs]
320.147: [GC pause (young) 226M->94M(256M), 0.1656664 secs]
325.978: [GC pause (年轻) 226M->93M(256M), 0.1475760 秒]
330.176: [GC 暂停 (年轻) 226M->94M(256M), 0.1727795 秒]

很久很久以后它仍然可以！

25882.894：[GC 暂停（年轻）224M->125M（256M），0.2126515 秒]
25884.880：[GC 暂停（年轻）224M->126M（256M），0.2059802 秒]
25887.027：[GC 暂停（年轻）224M->12 (256M), 0.1851359 秒]
25889.940: [GC 暂停 (年轻) 223M->126M(256M), 0.2046496 秒]
25891.567: [GC 暂停 (年轻) 224M->126M(256M), 0.1600574 秒]

再后来，一个完整的 GC

37180.191: [GC pause (young) 225M->154M(256M), 0.1716404 secs]
37182.163: [GC pause (young) (initial-mark) 225M->153M(256M)37182.326: [GC concurrent-mark-start], 0.1622246 secs]
37183.089: [GC concurrent-mark-end, 0.7635219 sec]
37183.090: [GC remark, 0.0032547 secs]
37183.093: [GC concurrent-count-start]
37183.297: [GC concurrent-count-end, 0.20433307]
3.2043307 ] GC 清理 198M->198M(256M), 0.0068127 秒]
37183.400: [GC concurrent-cleanup-start]
37183.400: [GC concurrent-cleanup-end, 0.0000393]
37183.648: [GC pause (young) 222M->153M(256M) , 0.1483041 秒]
37184.235: [GC 暂停 (部分) 171M->91M(256M), 0.2520714 秒]
37187.223：[GC 暂停（年轻）221M->92M（256M），0.1721220 秒]

更新

好吧，自从在 jdk1.6.0_18 上切换到 G1 垃圾收集器后，应用程序已经连续三天表现良好。我怀疑 Erik 对 VM在高吞吐量情况下将自己陷入死亡螺旋的情况的分析是正确的，因为它已经将对象提升到了终身代。