过去十几年CPU一直遵循着摩尔定律发展，单核频率越来越快，但是最近这几年，摩尔定律已然失效，CPU的工艺制程和发热稳定性之间难以取舍，取而代之的策略则是增加核心数量，目前家用电脑四核已经非常常见，服务器更是达到了32核64线程。为了有效地利用多核CPU，我们在代码层面就应该考虑到并发性。十几年的痛苦开发经历告诉我们，threads并不是获取并发性的好方法，往往会带来难以查找的bug，但是不用害怕，今天我们有很多其他方法来获得易用的并发性，比如我们接下来介绍的Actor模型。
Actor模型是一个概念模型，用于处理并发计算。它定义了一系列系统组件应该如何动作和交互的通用规则，最著名的使用这套规则的编程语言是Erlang。这篇文章更关注模型本身而不是它在不同语言的实现。
Actor模型和Actor
模型中一个Actor是一个基本的计算单元。它接受消息然后基于接到的消息做一些计算。和面向对象编程有些类似，一个对象被调用（接收到一个消息），基于调用方法（接受到的一个消息）做处理。区别是actor之间是完全隔离的，不共用内存区域。actor的私有状态不会被另外一个actor直接改变。
actor作为群体存在，单一的actor不是actor模式。在actor模型中，actor是唯一组成部分，actor带有地址以便互相发送消息。
actor按次序处理消息，比如你发送三个消息给一个actor，它们不会被并发处理。如果你想让这三个消息得到并发处理，你需要创建3个actor，然后分别发送给它们。
接受到的异步消息存在于actor内部的一个队列中，我们可以把它形象化的叫做邮箱（mailbox）。
actor的行为
当一个actor接受到消息后，它可以做如下事情：
- 创建更多的actor
- 发送消息到其他actor
- 指派对下一条消息做什么处理。
最后一条定义了actor如何操作内部状态。例如一个计算器作用的actor，初始状态是0，处理到加1消息时，它不改变内部状态，但分派下一条消息处理时，状态是1.
失败可容忍
Erlang语言中有个“由它失败”的思想。就是你不可能考虑到所有导致失败的问题，与其绞尽脑汁处理这些问题，不如让它自然失败，然后指派给失败处理者处理（例如恢复到稳定状态），在actor模型中，这是可行的。
actor之间的隔离性导致actor失败不会影响其他actor，监控者可以对自然失败的actor做直接处理而不会带来连锁问题。这让“自愈系统”成为可能，就是说一个actor异常后，监控者可以恢复一致性，可能以初始状态重起actor。
分布性
actor发消息时不在乎目标actor是本地运行的还是运行在其他节点。试想，如果actor只是只有内部状态的邮箱，只对消息做出反应，那就没人在乎它在哪里运行，知道有个地址让消息可以到达即可。这让我们可以创建分布式系统，并且在节点失败时独立恢复而不影响整个系统。
进一步建议看一下Erlang和Elixir语言， JVM上的 Actor库Akka，基于Actor的框架Vert.x
无锁
在使用Java/C# 等语言进行并发编程时需要特别的关注锁和内存原子性等一系列线程问题，而Actor模型内部的状态由它自己维护即它内部数据只能由它自己修改(通过消息传递来进行状态修改)，所以使用Actors模型进行并发编程可以很好地避免这些问题。Actor内部是以单线程的模式来执行的，类似于redis，所以Actor完全可以实现分布式锁类似的应用。
异步
每个Actor都有一个专用的MailBox来接收消息，这也是Actor实现异步的基础。当一个Actor实例向另外一个Actor发消息的时候，并非直接调用Actor的方法，而是把消息传递到对应的MailBox里，就好像邮递员，并不是把邮件直接送到收信人手里，而是放进每家的邮箱，这样邮递员就可以快速的进行下一项工作。所以在Actor系统里，Actor发送一条消息是非常快的。
隔离
每个Actor的实例都维护这自己的状态，与其他Actor实例处于物理隔离状态，并非像 多线程+锁 模式那样基于共享数据。Actor通过消息的模式与其他Actor进行通信，与OO式的消息传递方式不同，Actor之间消息的传递是真正物理上的消息传递。
