| 上一篇我们简介了Actor系统。说明了Actor之间存在着层次关系，它也是构成Actor应用的最主要的单位。 本篇介绍Actor本身的一些基本概念。 一个Actor包括了State（状态），Behavior（行为）。一个Mailbox（邮箱）和Supervisor Strategy (管理员策略），全部这些都封装在一个Actor引用之中（Actor Reference）。 Actor 引用 一个Actor对象须要和外界隔离开来才干构成一个Actor模型，因此从外部看，一个Actor对象由一个Actor引用来表示（想一想文件句柄的概念，这里有些相似)。一个Actor对象能够被传来传去。但从Actor系统外部一般无法窥视Actor内部的一些结构。 状态 一个Actor对象一般会包括一些变量，能够用来保存Actor当前的一些状态。这能够是一个有限状态机(FSM),一个计数器，等待处理的请求等。 正是因为这些状态才使得Actor变得有价值，而且这些状态须要保护起来以免被其他Actor破坏。一个好消息是Akka的Actor从概念上说都包括一个自己的轻量级的线程，全然和系统的其他部分分隔开来。这意味着你无需考虑同步互锁的情况。 而在幕后。Akka会在一种物理线程上执行多个Actor对象。一般是几个Actor共享一个物理线程。而某个Actor的兴许调用可能会使用不同的物理线程，而这些详细的实现细节对于Akka Actor使用者来说不须要了解。 因为Actor的内部状态对于Actor的操作非常重要。因此保持一致的状态什么必要，因此当一个Actor出错须要由其管理员重新启动时。其状态会又一次构造，就和最初创建Actor一样。 但也能够选择在Actor重新启动时恢复之前的某个存储点。 行为 每当处理一个信息时。它和Actor当前的某个行为做匹配，一个行为为一个函数，它定义了某些动作，也就是某个消息来时须要做的事。比方在用户通过验证是转发请求而在验证失败时拒绝请求。这些行为可能随时间而变化。 邮箱 一个Actor对象的作用是用来处理消息。这些消息能够由一个actor发给另外的actor对象（也能够来自外部actor)。 而用来连接发送者和接受者的部件就是邮箱。每一个Actor都有且仅仅有一个邮箱，全部发送者都将消息发送到这个消息队列，不同的发送者发送消息的顺序可能是随机发生的。而对于同一个发送者来说。发送消息的顺序和到达邮箱的顺序是一致的。 能够选择不同的邮箱实现，缺省为FIFO（先进先出队列).这对于通常情况来说是非常有利的，但对于某些情况，比方须要处理一些高优先级的消息，此时使用FIFO就不太合适了。 AKKa系统和其他Actor模型实现不同的一点是。当前的Actor行为必须处理下一个队列中的消息。没有办法能够扫描队列中匹配的消息。缺省情况下，假设某个消息没有处理将作为出错处理，除非你又一次定义这样的行为。 子Actor 每一个Actor都能够成为一个管理者（supervisor)。假设它创建用来处理子任务的子Actor对象。该Actor将自己主动管理子Actor。Actor的Context保存了其创建的一组子Actor对象并能够訪问他们。这个列表的改动能够通过创建(context.actorOf),停止(context.stop(child))等来完毕。 实际的创建和终止时异步发生的，因此创建和终止子Actor不会堵塞管理员Actor。 管理员策略 管理员策略用来处理子Actor出错时的情况。这些错误情况的处理由Akka依据定义的管理员策略来自己主动完毕。因为这些策略对于一个Actor系统的组成是最主要的，因此在Actor创建之后，管理员策略不能改动。 因为一个Actor仅仅能定义一个管理员策略，这意味着假设一个Actor的子对象须要不同的管理员策略时。那么须要一些中间层Actor来对这些子Actor进行分组。 终止Actor 当一个Actor中止（比方重新启动没有成功，自行终止，或者其管理员终止其执行），其占用的资源会被释放。并把其尚未处理的消息加入到系统的“死信邮箱”中。这些死消息会作为DeadLetter转发给EventSystem。其邮箱被替换成一个系统邮箱，将新收到的消息作为DeadLetter转发到EventSystem。 |