如何在底层线程上实现akka actor？

很长一段时间我对这个话题很困惑.我假设线程和演员之间存在某种关系.每个演员都有一个主持它的线程,所以我在想.可能每个线程都有几个actor在协同多任务模式下工作.

文档侧重于使用并轻松覆盖内部架构.你应该扩展Actor课程,你会得到工作的演员.所以我试着猜测如何做到这一点.并想象每个人Actor都有生命周期.像消息队列异步等待的东西.然后处理消息.去开始吧.

那是完全错误的假设.虽然文档说"演员生命周期"但它并不意味着Actor生命周期.提到的Actor是一个概念而不是实现Actor该类的实际对象.该对象在java堆中处于被动状态.

要将生活融入到概念中,需要协调一系列真正的工人.它的核心是调度员.它包含所有参与者,线程和消息.当资源可用并且有可用于处理的消息时,调度程序将激活.它需要适当的Actor对象,将其receive方法包装在runnable中并将其传递给备用线程.所以对象没有生命周期,只有来自actor系统的偶然方法调用.

当你想到它时,它比我早期假设的方案更有意义.但是我很难从可用的文档中推断出它.它是由经验丰富的并发程序员编写的.将演员类与演员背后的观念区分开来.他们知道,调度员的演员系统就像是一个操作系统任务调度.因此,他们很快就达到了目的,并描述了各种口味,并实现了每个人都熟悉的概念.

但对于新手来说,这并不容易.他对演员系统上下文中的调度程序模式一无所知.我试图谷歌"调度员模式",它只显示与演员系统定义不相关.

我发现很容易发送双重调度,多调度和其他OOP主题.我找到了类似于akka的路由器消息调度程序的东西.对于演员消息调度员来说可能有不错的描述,但它并不容易找到.

我希望我已经清除了误解.

在"我一直在寻找到的东西更像是说你给分拆出来的它的10个线程和50名演员一个线程池,如何通过批处理的10个线程处理这么多的演员？"

确切的行为取决于调度程序和配置.但是,大多数调度员基本上都是这样的:

选择具有非空邮箱的actor

然后派遣"演员"在执行者身上运行

消息被去除和处理的地方.

在可能的情况下,一些消息被一个接一个地取消并处理

在处理了一些消息(或者没有留下)之后,挑选另一个演员,以防止饥饿.(吞吐量参数)

上升并重复