Akka 参与者消息分配到调度程序线程

众所周知，调度程序线程负责执行actor消息。使用吞吐量参数，我们可以定义调度程序线程在移动到另一个参与者之前处理的消息数量

但我不确定dispatcher thread将如何挑选演员

比如说，我创建了10000个参与者，其中一次只有1000个参与者接收消息，其余9000个参与者处于空闲状态，dispatcher线程数为200

dispatcher线程将按哪个顺序拾取参与者的消息。它是否也会检查邮箱中的消息

---

有人能解释一下dispatcher线程选择actor邮箱消息的流程吗。

Lightbend讨论论坛的X-Post：

在我开始之前，简短的回答是“别担心”。我理解这种奇怪，但在微观层面上，它将是不确定的，从宏观层面上来说，您需要关心的唯一问题是，常规分派器、固定分派器、fork-join和线程池执行器之间的差异，以及文档中的排序保证

另外，免责声明，我并不声称自己是dispatchers内部的专家：我只是一个最终用户。但是我有点拖拉，我想我应该分享一些我的调优观察结果，并稍微浏览一下Akka源代码。要获得更详细的答案，您还应该查看源代码。您要查找的大多数答案都将在文件夹中

有了免责声明，让我先回答你的第二个问题

“调度程序是否也会检查邮箱中是否有空闲的参与者来接收邮件？”

调度员实际上没有检查任何东西：它完全是被动的。（稍后我们将看到）它当然不会浪费任何时间检查空邮箱。这就是为什么一个调度器可以扩展到数百万个参与者

您更一般的问题“dispatcher thread将如何选择演员？”更难用简单的方式回答。有这么多类型的调度员。我能给你的每一个答案都会有例外。（例如，前面提到的pinted dispatcher，其中线程专用于特定的参与者，CallingReadDispatcher设计用于测试和运行当前线程上的所有调用）。但让我谈谈典型情况下的典型调度员

Dispatchers不选择参与者，Dispatchers（在典型情况下）只是Java服务的接口。典型的场景如下所示：

• 将邮件添加到参与者的邮箱中。（从调度员的角度来看，我们对世界的看法是相反的：我们与邮箱交互，而不是与参与者交互。）
• 如果邮箱尚未调度（如果其中包含邮件，则可能已经调度），则邮箱将转到其调度程序并自行调度
• 调度器转到底层ExecutorService（比如ForkJoinExecutor）并将任务排队以处理邮箱
• Java是一种语言，我并不自称是专家。但简短的版本是，每个线程都有自己的队列，但当它有一个空队列时，它能够从其他队列中“窃取”任务。Java实现还能够动态调整正在使用的线程数量，直到达到并行限制。这就是为什么我说“微观层面”是不确定的。窃取动态线程的工作非常有效，但它不是确定性的
• 在某个时刻，与包含邮件的邮箱相关的任务将由执行器选择，并将调用Runnable
• Runnable将首先处理邮箱中的系统消息，然后处理常规消息。这里也有各种例外情况，如优先级邮箱、隐藏、吞吐量限制等。但通常情况下，邮箱将处理消息（使用参与者的行为），直到邮箱为空或达到其中一个吞吐量限制。请注意，任务绑定到邮箱，而不是邮件

以上内容过于简单，忽略了一些边缘情况和性能优化，但这是30000英尺的视图

---

我希望这能有所帮助，因为我知道它充满了异常（邮箱和调度器的设计非常灵活）和复杂。但是Akka是高度优化的，效率极高。如果任何Akka开发人员想介入，告诉我我的描述在哪里变得马虎，请随意。但最终的结果是我的出发点：这里有多个抽象层，因此您得到的唯一排序保证是有文档记录的，但总体系统吞吐量非常高效，即使每条消息完成的工作很小且消息数量很大。

Lightbend讨论论坛的X-Post：

在我开始之前，简短的回答是“别担心”。我理解这种奇怪，但在微观层面上，它将是不确定的，从宏观层面上来说，您需要关心的唯一问题是，常规分派器、固定分派器、fork-join和线程池执行器之间的差异，以及文档中的排序保证

另外，免责声明，我并不声称自己是dispatchers内部的专家：我只是一个最终用户。但是我有点拖拉，我想我应该分享一些我的调优观察结果，并稍微浏览一下Akka源代码。要获得更详细的答案，您还应该查看源代码。您要查找的大多数答案都将在文件夹中

有了免责声明，让我先回答你的第二个问题

“调度程序是否也会检查邮箱中是否有空闲的参与者来接收邮件？”

调度员实际上没有检查任何东西：它完全是被动的。（如我们所愿