我一直看到两个 Actor 之间有很长的延迟(60 秒以上)，从第一个 Actor 为第二个 Actor 发送消息到第二个 Actor 的 onReceive 方法是实际上用消息调用。我可以寻找什么样的东西来调试这个问题？
详情
ActorA 的每个实例都使用 ActorRef.tell(Object, ActorRef) 为 ActorB 发送一条消息。我在调用 ActorA 中的 tell 方法后立即收集了一个毫秒时间戳(使用 System.currentTimeMillis())，并在 ActorB 的 onReceive(对象)。这些时间戳之间的间隔始终为 60 秒或更长时间。具体而言，当随时间绘制时，此间隔遵循大致的锯齿模式，范围从 60 秒到近 120 秒不等，如下图所示。
这些actor处于系统数据流的早期，在ActorB之后还有其他几个actor。这种大的差距只发生在这两个特定的 Actor 之间，其他对相邻 Actor 之间的差距通常小于一毫秒，偶尔也有几十毫秒。此外，在任何给定 actor 内部花费的实际时间绝不会超过一秒。
通常，系统中的每个参与者只将一条消息传递给另一个参与者。其中一个参与者(在 ActorB 之后)向几个不同的参与者中的每一个发送一条消息，并且在一小部分(小于 0.1%)的时间里，某些参与者会向同一个后续参与者发送多条消息(即，多个后续 Actor 的实例将被要求)。发生这种情况时，多条消息的数量通常约为十几个或更少。
这可以用 Akka 的正常 react 性质来(明确地)解释吗？它是否表明工作分配方式或参与者配置方式存在问题？有什么东西可以明确地阻止特定 Actor 旋转起来吗？我应该收集或查看哪些其他信息以了解其来源，或了解它是否真的是一个问题？
最佳答案
您的线程池有限。如果您的 Actors 阻塞，它们仍会占用线程池中的空间。如果您的线程池已饱和，则不会创建新线程。
您可能需要配置
核心池大小因子，
core-pool-size-min，和
核心池大小最大值。
如果您希望某些操作被阻止，您可以将它们包装在 Future { blocking { ... } } 中并注册一个回调。但最好使用异步、非阻塞调用。
关于java - Akka Actor 之间的长时间延迟，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33267469/