一个actorSystem 是一个重量级的结构。它会分配N个线程。所以对于每一个应用来说只用创建一个ActorSystem。
Actor是种可怜的“生物”，它们不能独自存活。Akka中的每一个Actor都是由一个Actor系统（Actor System）来创建和维护的。一个Actor系统会提供一整套辅助功能，
树形结构
actors以树形结构组织起来，类似一个生态系统。例如，一个actor可能会把自己的任务划分成更多更小的、利于管理的子任务。为了这个目的，它会开启自己的子actor，并负责监督这些子actor。关于监督的具体细节就不在这里讨论了。我们只要知道一点，就是每一个actor都会有一个监督者，那就是创建这些actor的那个actor。
如下图：
actor系统的精华就是任务的分解。任务要被分割的要足够小，每个分片都会被委托给子actor。这里用到的思想很明显就是“分而治之”，万变不离其宗啊！要想做好这一切，不仅仅要把任务组织的非常清晰（利于分解），也要对处理任务的最终actor在以下方面进行考虑：哪些消息需要处理、如何正常的回应、如何处理失败等等。如果一个处理特定任务的actor失败了，它会向它的监督者发出响应错误的消息去寻求错误处理的方法。这种递归式（监督者也有自己的监督者）的结构可以保证错误在合适的级别上进行处理。
你的应用程序是由几十个还是几百万个Actor来组成取决于你的用例，但是Akka完全有能力处理百万级别数量的Actor，你可能觉得创建这么多Actor一定是疯了，但实际上，Actor和线程之间并不是一一对应的关系，这一点非常重要，否则系统的内存很快就会被耗光的。由于Actor的非阻塞特性，一个线程可以为不同的Actor服务，Akka（译者注：具体地说是Dispatcher)会让线程在不同的Actor之间切换，依据是当前谁有消息需要被处理就分配线程给它。为了了解实际发生了什么。
消息的发送和处理完成是一个异步的非阻塞的过程。发送方不会一直被阻塞到接收方处理完消息，它会直接继续它自己的工作，发送方可能会期望从处理方那里得到一个反馈消息，但也许它根本不关心消息的处理结果。当某些组件发送一条消息给一个Actor时，真正发生的事情是：这个消息被投递给了这个Actor的Mailbox， 我们基本上可以把Mailbox当成一个对列。把一条消息放到一个Actor的Mailbox的过程也是非阻塞的，比如：发送方不会一直等待消息进入接收方的Mailbox对列。
Dispatcher会通知Actor它的Mailbox有一条新消息，如果这个Actor正在处理着手头上的消息，Dispatcher会从当前的执行上下文里选一个可用的线程，一旦Actor处理完前面的消息，它会让Actor在这个准备好的线程上从Mailbox里取出这条消息去处理。Actor会阻塞分配给它的线程直到它开始处理一条消息，但这并不会阻塞消息的发送方，这意味着一个耗时较长的操作会影响整体的性能，因为所有其他的Actor不得不被安排从剩余线程中选取一个去处理消息（译者注：增加了线程调度的开销）。
因此，你的Receive偏函数要遵从一个核心的准则：尽可能地缩短它的执行时间（译者注：可以把任务分解为更小的单元委派更粒度更细的Actor去执行）。更重要的是，在你的消息处理代码里尽量地避免调用会造成阻塞的代码。当然，有些事情是你无法完全避免的，比如，当今主流的数据库驱动基本都是阻塞的，如果你想让你的程序基于Actor去持久化或查询数据时，你就会面临这样的问题。现在已经有一些应对这类问题的方案了，但是作为一偏介绍性的文章，本文先不涉及。
如何创建一个actor实例？
用new方法？这样不行！Akka会用一个ActorInitializationException异常回敬你。事情是这样的：为了能让Actor良好地工作，你的Actor必须交给ActorSystem和它的组件来托管。因此，你需要通过ActorSystem来帮你创建这个实例：
定义在AcotorSysytem上actorOf方法期望一个Props实例，针对新建的Actor的配置信息都会封装到这个Props实例里，
注意：actorOf返回的对象类型不是Barista而是ActorRef（译者注：Akka对Actor的托管体现在很多地方，前面提到的你不能直接创建一个Actor实例是一方面，此处，创建之后你得到的也不是Actor实例本身而是一个ActorRef）。Actor从不会与其他Actor直接通信，因此没有必要获取一个Actor实例的直接引用，而是让Actor或其他组件获取那些需要发送消息的Actor的ActorRef。
因此,ActorRef扮演了Actor实例代理的角色，这样做会带来很多好处，因为一个ActorRef可以被序列化，我们可以让它代理一个远程机器上的Actor，至于ActorRef后面的这个Actor是本地JVM里的还是一个远程机器上的，这对使用者来说都是透明的，我们把这种特性称作“位置透明”。
请记住，ActorRef不是类型参数化的，任何ActorRef都可以互相交换，以便可以让你发送任意的消息给任意的ActorRef。这种设计我们前面也提到了，它让你可以简单地修改你的Actor系统的网络拓扑而不需要对发送方做任何修改。
问询（Ask）机制：
有时候，给一个Actor发送消息然后期待返回一个响应消息这种模式并不适用于某些场景，最常见的例子是当某些组件并不是Actor但又需要和Actor交互时，它们就无法接收来自Actor的消息。对于这种情况，Akka有一种Ask机制，它在基于Actor的并发和基于Future的并发之间提供一座桥梁.
定义一个actor:
在Java里面，角色是通过继承UntypedActor 类及实现onReceive方法来实现的.这个方法将message作为参数。
Props:
用Props创建角色:
final ActorRef testActor = system.actorOf(Props.create(ProduceActor.class));
发送信息:
向actor发送消息是使用下列方法之一。
意思是“fire-and-forget”， e.g. 异步发送一个消息并立即返回。也称为 tell.
异步发送一条消息并返回一个 Future代表一个可能的回应。也称为 ask.
接收信息:
当一个角色收到被传递到onReceive方法的消息
转发消息:
你可以将消息从一个角色转发给另一个。虽然经过了一个‘中转’，但最初的发送者地址/引用将保持不变。当实现功能类似路由器、负载均衡器、备份等的角色时会很有用。同时你需要传递你的上下文变量。
target.forward(result, getContext());
回复信息：
如果你需要一个用来发送回应消息的目标，可以使用 getSender, 它是一个角色引用。 你可以用 getSender().tell(replyMsg, getSelf())向这个引用发送回应消息。
你也可以将这个ActorRef保存起来将来再作回应。如果没有sender (不是从actor发送的消息或者没有future上下文) 那么 sender 缺省为 ‘死信’ 角色的引用。
supervisorActor.tell(akka.actor.PoisonPill.getInstance(), ActorRef.noSender());
ctorSystem.terminate();
PoisonPill：
你也可以向角色发送 akka.actor.PoisonPill 消息, 这个消息处理完成后角色会被终止。 PoisonPill 与
杀死一个角色：
victim.tell(akka.actor.Kill.getInstance(), ActorRef.noSender());