Actor模型

线程挂起：休息，需要时唤醒；

线程睡眠：休息，在某时某刻激活继续工作；

线程阻塞：休息，被指派的任务到来则激活继续工作；

actor模型：

Actor模型为并行而生，具Wikipedia中的描述，它原本是为大量独立的微型处理器所构建的高性能网络而设计的模型。而目前，单台机器也有了多个独立的计算单元，这就是为什么在并行程序愈演愈烈的今天，Actor模型又重新回到了人们的视线之中了。Actor模型的理念非常简单：天下万物皆为Actor，Actor之间通过发送消息进行通信。Actor模型的执行方式有两个特点：

1. 每个Actor，单线程地依次执行发送给它的消息。
2. 不同的Actor可以同时执行它们的消息。

对于第1点至今还有一些争论，例如Actor是否可以并行执行它的消息，Actor是否应该保证执行顺序与消息到达的一致（祥见Wikipedia的相关词条）。而第2点是毋庸置疑的，因此Actor模型天生就带有强大的并发特性。我们知道，系统中执行任务的最小单元是线程，数量一定程度上是有限的，而过多的线程会占用大量资源，也无法带来最好的运行效率，因此真正在同时运行的Actor就会少很多。不过，这并不影响我们从概念上去理解“同一时刻可能有成千上万个Actor正在运行”这个观点。在这里，“正在运行”的含义是“处于运行状态”。

Actor模型实现：

提到Actor模型的实现就不得不提Erlang。Erlang专以Actor模型为准则进行设计，它的每个Actor被称作是“进程（Process）”，而进程之间唯一的通信方式便是相互发送消息。一个进程要做的，其实只是以下三件事情：

• 创建其他进程
• 向其他进程发送消息
• 接受并处理消息

loop() ->    receive        {From, {store, Key, Value}} ->            put(Key, {ok, Value}),            From ! {kvs, true},            loop();        {From, {lookup, Key}} ->            From ! {kvs, get(Key)},            loop()    end.

Actor模型的任务调度：

Actor模型的任务调度方式分为“基于线程（thread-based）的调度”以及“基于事件（event-based）的调度”两种。

基于线程的调度为每个Actor分配一个线程，在接受一个消息（如在Scala Actor中使用receive）时，如果当前Actor的“邮箱（mail box）”为空，则会阻塞当前线程直到获得消息为止。基于线程的调度实现起来较为简单，例如在.NET中可以通过Monitor.Wait/Pulse来轻松实现这样的生产/消费逻辑。不过基于线程的调度缺点也是非常明显的，由于线程数量受到操作系统的限制，把线程和Actor捆绑起来势必影响到系统中可以同时的Actor数量。而线程数量一多也会影响到系统资源占用以及调度，而在某些情况下大部分的Actor会处于空闲状态，而大量阻塞线程既是系统的负担，也是资源的浪费。因此基于线程的调度是一个拥有重大缺陷的实现，现有的Actor Model大都不会采取这种方式。

于是另一种Actor模型的任务调度方式便是基于事件的调度。“事件”在这里可以简单理解为“消息到达”事件，而此时才会为Actor的任务分配线程并执行。很容易理解，我们现在便可以使用少量的线程来执行大量Actor产生的任务，既保证了运算资源的充分占用，也不会让系统在同时进行的太多任务中“疲惫不堪”，这样系统便可以得到很好的伸缩性。在Scala Actor中也可以选择使用“react”而不是“recive”方法来使用基于事件的方式来执行任务。

现有的Actor Model一般都会使用基于事件的调度方式。不过某些实现，如MS CCR、Retlang、Jetlang等类库还需要客户指定资源分配方式，显式地指定Actor与资源池（即线程池）之间的对应关系。而如Erlang或Scala则隐藏了这方面的分配逻辑，由系统整体进行统一管理。前者与后者相比，由于进行了更多的人工干涉，其资源分配可以更加合理，执行效率也会更高——不过其缺点也很明显：会由此带来额外的复杂度。

Erlang的优势与缺陷：

Erlang在消息执行方式上的优势在于灵活。Erlang是弱类型语言，在实现的时候可以任意调整消息的内容，或是模式的要求。在Erlang进行模式匹配时往往有种约定：使用“原子”来表示“做什么”，而使用“绑定”来获取操作所需要的“数据”，这种方式避免了冗余的cast和赋值，在使用的时候颇为灵活。然而，世上没有完美的事物，Erlang的消息执行方式也有缺陷，而且是较为明显的缺陷。

首先，Erlang的数据抽象能力实在太弱。如果编写一个略显复杂的应用程序，您会发现程序里充斥着复杂的元组。您可能会疲于应对那些拥有7、8个单元（甚至跟多）的元组，一个一个数过来到底某个绑定匹配的是第几项，它的含义究竟是什么——一旦搞错，程序便会出错，而且想要调试都较为困难。因此，也有人戏称Erlang是一门“天生会损害人视力的语言”（令人惊讶的是，那篇文章居然搜不到了，我们只能从搜索引擎上看出点痕迹了）。

而我认为，这并不是Erlang语言中最大的问题，Erlang中最大的问题也是其“弱类型”特性。例如，现在有一个公用的Service Locator服务，任意类型的Actor都会像SL发送一个消息用于请求某个Service的位置，SL会在得到请求之后，向请求方发送一条消息表示应答。试想，如果SL的功能需要有所修改，作为回复的消息结构产生了变化，那么我们势必要修改每一个请求方中所匹配的模式。由于消息的发送方和接受方在实际上完全分离，没有基于任何协议，因此静态检查几乎无从做起。一旦遇到这种需要大规模的修改的情况，Erlang程序便很容易产生差错。因为一旦有所遗漏，系统便无法正常执行下去了。

我们究竟要解决什么问题：

Actor模型的本质已经被强调了无数遍：万物皆Actor。Actor之间只有发送消息这一种通信方式，例如，无论是管理员让工作者干活，还是工作者把成果交还给管理员，它们之间也要通过发送消息的方式来传递信息。这么做看似不如直接方法调用来的直接，但是由于大量的消息可以同时执行。同样，消息让Actor之间解耦，消息发出之后执行成功还是失败，需要耗费多少时间，只要没有消息传递回来，这一切都和发送方无关。Actor模型的消息传递形式简化了并行程序的开发，使开发人员无需在共享内存（确切地说，其实是共享“写”）环境中与“锁”、“互斥体”等常用基础元素打交道。不过，使用Actor模型编写应用程序，需要开发人员使用一种与以往不同的设计思路，这样的思路说难倒不难，说简单也不简单。等我们有了成熟、稳固的Actor模型之后再回头来探究这种特殊的架构方式。

由于Actor执行的唯一“事件”便是接受到了一个消息，而一个Actor很可能会做多件事情，因此我们一定需要一种机制，可以把消息“分派”到不同的“逻辑段”中去，并为不同的逻辑指定各自所需要的参数。例如，Person是一个Actor类型，它有三种任务，不同的任务会带有不同参数：

1. 聊天（Chat）：指定另一个Person对象（聊天的另一方），以及一个Topic对象（聊天的话题）。
2. 吃饭（Eat）：指定一个Restaurant对象（餐馆）。
3. 干活（Work）：指定一个Person对象（工作完成后的汇报人），以及一个Job对象（任务）。

当Person对象获得一条消息时，它需要将其识别为聊天、吃饭或干活中的一种，再从中获取到这个行动所需要的数据。