何时应使用Actor Model？
它当然不能保证无死锁的环境。
演员A可以等待B的消息，而B等待A。
此外，如果演员必须确保已处理其消息，然后再继续执行下一个任务，则它必须发送消息并等待“您的消息已处理”消息，而不是直接阻止。
模型的力量是什么？] >>
何时应使用Actor模型？它当然不能保证无死锁的环境。演员A可以等待B发出的消息，而演员B必须等待其......>
考虑到一些并发问题，您将寻找什么决定是否使用参与者？
首先，我要定义问题...的主要动机是嵌套for循环或递归的加速吗？如果是这样，那么简单的基于任务的方法或并行循环方法将可能对您（而不是参与者）有效。
但是，如果您有一个涉及依赖项和协调共享状态的更复杂的系统，那么参与者方法可以提供帮助。特别是通过使用actor和消息传递语义，您通常可以通过实际复制状态（消息）并对它们做出反应来避免使用显式锁来保护共享状态。
至少在两种情况下，Actor的使用是“自然的”：
Actor是异步的并发的，但是不能保证消息的执行顺序或时间限制。因此，原子事务不能拆分为参与者。
如果应用程序/任务不涉及任何可变状态，则Actor会过大，因为Actor框架会竭尽全力避免竞争条件。