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