我想知道Futures是否更适合与Actors一起使用，而不是在不使用Actor的程序中。换句话说，正在进行异步计算，以及将来最好在Actors系统中完成的事情吗？
这就是我说的原因：
1 - 您执行计算结果，将触发您可能在另一个线程中执行的某些操作。
例如，我有一个很长的操作来确定某些东西的价格，从我的主线程，我决定为它启动一个异步过程。与此同时，我可以做其他事情，然后当响应准备好/可用或传回给我时，我继续前进。
我可以看到使用actor这很方便，因为你可以将结果传递给一个actor。但是使用典型的线程模型，您可以阻止或....？
2 - 另一个问题，就是说我需要通过在线获取一些信息来更新参与者列表的年龄。假设我只有一个未来的任务。关闭参与者列表是不是做错了。多个线程可能同时访问该参与者列表。所以在未来进行更新根本就是错误的，在那种情况下，我们需要java并发集合不是吗？
也许我认为这是错误的方式，未来并不意味着做副作用 在所有
但在这种情况下，公平，没有副作用，但我们仍然存在从调用线程获取值的问题，这只能阻塞。我的意思是让我们想象一下，结果会帮助调用线程更新一些数据结构。如何在不以某种方式关闭该数据结构的情况下异步更新。
我相信像OnComplete这样的回调可以用于 副作用（它在这儿吗？）
然而，无论如何，回调都必须关闭数据结构。因此，我不知道如何使用Actor。
PS：我喜欢演员，我只是想在没有演员的情况下更好地理解未来的用法。我到处读，只有在需要管理状态时才应该使用actor。在我看来，总的来说，使用future，没有actor，总是涉及阻塞某个地方，如果结果需要在某个时候传回给发起异步任务的线程。答案 0 :(得分：5)
当您处理可变状态时，Actor很好，因为它们封装了可变状态。并且只允许基于消息的交互。
您可以使用Future在其他线程中执行。您不必阻止Future，因为Scala的Future撰写。因此，如果您的代码中有多个期货，则无需等待/阻止所有期货竞争。例如，如果您的管道完全是非阻塞或asyn（例如，播放和喷涂），您可以将Future返回给客户端。
与演员相比，期货是轻量级的，因为您不需要完整的演员系统。
以下是Martin Odersky的一句话，我非常喜欢。
所有并发问题都没有灵丹妙药;正确的 解决方案取决于人们需要实现的目标。你想定义吗？ 对事件或值流做出反应的异步计算？ 或者通过消息进行自主，孤立的实体通信？要么 在可变商店上定义交易？或者，也许是主要的 并行执行的目的是提高性能？对于每一个 在这些任务中，有一个完成工作的抽象：期货， 反应流，演员，事务记忆或并行 集合。
因此，请根据您的使用案例和需求选择您的抽象。