Actor模式是一个解决分布式计算的数学模型，其中Actor是基础，它能回应接收到消息，能够自我决策，创建更多的Actor，发送更多的消息，决定 如何回应下一个接收到的消息。Actor认为一切皆是Actor，类似于面向对象认为一切皆Object一样。OO的执行是顺序的，Actor模型内在设 计就是并行的。
Actor是计算实体，它回复接收到的消息，能够并行的：
1. 发生有限的消息给其他Actor
2. 创建有限数目的新Actor
3. 指定小一个消息到达时的行为
这些操作并没有顺序要求，它们能够并行地实施。由于没有对消息的时序做规定，Actor模式是一种异步模型，发送到Actor不等待消息被接收而继续执行。Actor之间不共享状态，如果想获取其他actor的状态，只能通过消息请求的方式。
Actor在消息内部指定接收消息的Actor地址。Actor可以用自己的地址发送消息，相当于自己接收到自发发送到消息，可以驱动自己的状态。
Carl Hewitt(
http://arxiv.org/abs/1008.1459)总结了信息系统的一些基本原则：
1. 持久化（Persistence），采集和索引信息
2. 并发性（Concurrency）
3. Quasi-commutativity，信息不论是新产生的，还是与现在进行时的任务相关的，都是有用信息
4. 受资助的（Sponsorship），资助者提供计算资源，比如处理器，存储忽然通信设施
5. 多元化（Pluralism），信息是异构重叠的，经常还是不一致的
6. 可溯源（Provenance），信息被仔细地追踪和记录
并且认为Actor Model为非一致性鲁棒性信息系统提供了坚实基础。（他是Actor的作者，难免打下广告啦）
但是为什么Actor Model没有得到广泛的应用呢？Paul Mackay（
http://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol2/pjm2/）回答了这一问题。Actor模型提出的时候，分布式计算才刚刚诞生，一切才刚刚开始，虽然Actor非常适合解决分布式的一些问题，但由于实现的复杂性，一开始并没有吸引多少注意。他还列举了Actor模型的一些不足：
1. Actor提供了模块和封装，缺少继承和分层。
2. 由于Actor能够动态创建其他Actor，这种行为使得系统的行为动态变化，很难控制。
3. 行为置换（behaviour replacement）。由于行为是动态的，很难用静态语言实现。静态分享不能支持反射，运行系统的重新配置。优化困难。为了保证消息的可靠传递，需要无限制的邮箱，需要的无线堆栈在某些架构下并不能满足。
4. 异步消息对于某些范式和算法并不适合。比如对消息顺序有严格要求的系统，虽然可以通过等待实现，但会严重降低Actor模型的效率。在OOP中，Actor会增加Actor的数量，增加系统开销。
参考资料：
The Actor Model - Towards Better Concurrency
http://www.slideshare.net/drorbr/the-actor-model-towards-better-concurrency
Acator in Scala中文翻译
http://blog.csdn.net/strongerbit/article/details/6838162
Foundations of Actor Semantics
http://dspace.mit.edu/bitstream/handle/1721.1/6935/AITR-633.pdf?sequence=2ActorLite：
ActorLite：一个轻量级Actor模型实现（上）
http://blog.zhaojie.me/2009/05/a-simple-actor-model-implementation.html
The Scala Actors API
Scala.Actor实践心得与设计思想
http://www.cnblogs.com/shiyangxt/archive/2011/07/30/2121663.html
Actor模型