Actor 系统

注释：ActorSystem是一个重量级架构，它将分配个线程，因此为每个逻辑应用程序都创建一个线程。

就像在经济组织中一样，Actor 自然形成等级制度。一个负责监督程序中某个函数的 Actor 可能希望将其任务拆分为更小、更易于管理的部分。为此，它启动了由它监督的子 Actor。在「这里」解释监督细节的同时，我们将集中讨论本节中的基本概念。唯一的先决条件是要知道每个 Actor 只有一个监督者，这就是创建它的 Actor。

Actor 系统的典型特征是，任务被拆分和委托，直到它们变得足够小，可以一块处理。这样做，不仅任务本身结构清晰，而且结果 Actor 可以根据他们应该处理哪些消息、应该如何正常反应以及应该如何处理失败来进行推理。如果一个 Actor 没有处理特定情况的方法，它会向其监督 Actor 发送相应的失败消息，请求帮助。然后，递归结构允许在正确的级别处理故障。

现在，设计这样一个系统的困难在于如何决定谁应该监督什么。没有单一的最佳解决方案，但有一些指导方针可能会有所帮助：

如果一个 Actor 管理另一个 Actor 正在做的工作，例如通过传递子任务，那么管理 Actor 应该监督子 Actor。原因是管理 Actor 知道预期的故障类型以及如何处理。
如果一个 Actor 依靠另一个 Actor 来履行职责，它应该观察另一个 Actor 的活动，并在接到终止通知后采取行动。这与监督不同，因为监督方对监督策略没有影响，应该注意的是，单独的功能依赖性并不是决定将某个子 Actor 放在层级中何处的标准。

这些规则总是有例外的，但是不管你是遵守规则还是违反规则，你都应该有一个理由。

Actor 应该像好的同事一样：高效地工作，而不是不必要地打扰其他人，并且避免占用资源。翻译成编程语言，这意味着以事件驱动的方式处理事件并生成响应（或更多请求）。Actor 不应在可能是锁、网络套接字等外部实体上阻塞，即占用线程时被动等待，除非这是不可避免的；对于后一种情况，请参见下文。
不要在 Actor 之间传递可变对象。为了确保这一点，最好选择不可变的消息。如果通过将它们的可变状态暴露到外部来破坏 Actor 的封装，则会返回正常的 Java 并发域，并存在所有的缺点。
顶级 Actor 是错误内核的最核心部分，因此要谨慎地创建它们，并且更倾向于真正的分层系统。这对于故障处理（同时考虑配置的粒度和性能）有好处，而且它还减少了对守护者 Actor 的压力，如果使用过度，这是一个单一的竞争点。

Actor 系统管理配置使用的资源，以便运行其包含的 Actor。在一个这样的系统中，可能有数百万的 Actor，毕竟所有的赞歌（）都是将他们视为丰富的，并且他们在每个实例的开销只有大约 300 字节。当然，在大型系统中处理消息的确切顺序不受应用程序作者的控制，但这也是无意的。

当你知道应用程序的所有操作都已完成时，可以调ActorSystem的方法。这将停止守护者 Actor，而守护者 Actor 又将递归地停止其所有子 Actor，即系统守护者。

英文原文链接：.