Actor模型

Actor模型于1970年年初被提出，为并行计算而生，理念非常简单：所有对象皆Actor，在Actor之间仅通过发送消息进行通信，所有操作都是异步的，不同的Actor可以同时处理各自的消息，使整个系统获得大规模的并发能力。但是，该理念在当时有些超前，因此很快被人遗忘。直到Erlang这种基于Actor模型设计的面向并发编程的新语言横空出世，在并发领域竖起一座丰碑，Actor模型才再次成为分布式计算领域的热点技术之一。

目前，几乎在所有主流开发平台下都有了Actor模型的实现：Java平台下Scala的Actor类库和Jetlang；NET平台下的MS CCR和Retlang；F＃平台下的MailboxProcessor；微软基于MS CCR构建的新语言Axum。

我们可以认为Actor模型是面向对象模型在并发编程领域的一个扩展。Actor模型精心设计了消息传输和封装的机制，强调了面向对象。我们可以将一个Actor类比为一个对象，对象提供了方法以供其他对象调用，等价于一个Actor可以处理某些类型的消息并进行响应，但与方法调用不同，Actor之间的消息通信全部是异步模式，避免了同步方法调用可能产生的阻塞问题，因此很适合高度并行的系统。但是，异步编程这种思维模式大大增加了我们在编程中所耗费的脑力劳动，很难被习惯了CRUD的大众程序员们所接受，所以注定了Actor模型曲高和寡的命运。

从另一方面来考虑，Actor模型大大简化了并行编程的复杂度。我们知道，对象一般都有属性（状态），但如何高效、安全地处理对象的可变属性，成为多线程并发编程领域中公认的编程难题。比如Java为了解决这一难题，先后设计了volatile变量、Atomic变量、基于Atomic的CAS原子计数器指令、轻型的Lock锁，最后祭出了Java并发领域专家Doug Lea教授潜心数年编写的难度极高的并发集合框架——Java Concurrent Collection。但是即使从业多年，我们依然难以写出一段工业级质量的多线程代码。Actor之父——Carl Hewitt很早就敏锐地意识到了这个问题，于是定义了Actor的第2个重要特性：Actor模型的内部状态不能被其他Actor访问和改变，除非发送消息给它。那么消息是否可变呢？显而易见，Actor发出的消息也是不可变的。Actor模型舍弃了共享变量和共享内存这种常规编程模式，虽然失去了一定的灵活性，却让任意两个Actor都具备了跨越网络实现分布式计算的天然基因，从而成就了其在大规模分布式计算领域的“不老传说”。

Actor模型的优点很明显，即将消息收发、线程调度、处理竞争和同步的所有复杂逻辑都委托给了Actor框架本身，而且对应用来说是透明的。我们可以认为Actor只是一个实现了Runnable接口的对象，在关注多线程并发问题时，只需要关注多个Actor之间的消息流即可。此外，符合Actor模型的程序也很容易被测试，因为任意一个Actor都可以被单独进行单元测试。如果测试案例覆盖了该Actor所能响应的所有类型的消息，就可以确定该Actor的代码十分可靠。

那么，Actor模型的缺点有哪些呢？简单总结如下。

● Actor完全避免共享并且仅通过消息传递进行交流，使得程序员失去了精细化并发调控的能力，所以不太适合实施细粒度的并行且可能导致系统响应延时的增加。如果在Actor程序中引入一些并行框架，就可能导致系统的不确定性。

● 尽管使用Actor模型的程序比使用线程与锁模型的程序更容易调试，Actor模型仍会出现死锁这一类共性问题，也会出现一些Actor模型独有的问题（例如信箱溢出）。

此外，Actor平台实现起来较为复杂，而且平台的性能取决于其实现原理与底层机制，比如分布式情况下的消息传输机制、网络通信机制及消息到Actor的派发机制，在这些方面如果有处理不好的地方，就会导致整体性能和稳定性问题。比如某个Actor因为某个错误陷入死循环，疯狂地消耗CPU，基本上整个系统就瘫痪了，其他Actor很难有机会正常工作，此时Java上的Akka平台由于根本做不到公平调度，在出现这种问题时什么也调度不了，只能等待操作系统切换线程。而Erlang尽力实现了“可抢占的公平”调度，比较好地解决了这一难题。