任何在过去做过多线程的人都不会否认管理多线程应用程序有多么困难和痛苦。我说管理因为它开始很简单，一旦你开始看到性能改进，它变得非常有趣。但是，当您发现没有更简单的方法从子任务中的错误中恢复或者您发现难以重现的僵尸错误或者当您的探查器显示您的线程花费大量时间阻塞时，它会很疼在写入共享状态之前浪费了。

我不想谈论Java并发API及其集合如何使它更好更容易，因为我确信如果你在这里，你可能需要更多地控制子任务或者仅仅因为你不喜欢写锁和同步块并且更喜欢更高级别的抽象。

在本系列的Akka Notes中，我们将通过简单的Akka示例来探索我们在工具箱中的各种功能。

什么是演员？

Akka的演员遵循演员模型（呃！）。

像人一样对待演员。不亲自交谈的人。他们只是通过邮件交谈。

让我们稍微扩展一下。

消息传递

考虑两个人 - 一个聪明的老师和学生。学生每天早上都会向老师发送一封邮件，明智的老师会发回一个明智的报价。

注意事项：

1. 学生发送邮件。发送后，无法编辑邮件。谈论自然不变性。
2. 老师在他希望的时候检查他的邮箱。
3. 教师还发送回邮件（再次不可变）。
4. 学生在他自己的时间检查邮箱。
5. 学生不等待回复。（没有阻止）

这几乎总结了Actor模型的基本块 - 传递消息。

2.并发

现在，想象一下有3位聪明的老师和3位学生 - 每个学生都会向其他老师发送笔记。那么会发生什么？实际上没有任何改变。每个人都有自己的邮箱。这里要注意的一个微妙点是：

默认情况下，邮箱中的邮件按其到达的顺序进行读取/处理。

在内部，默认情况下它是ConcurrentLinkedQueue。而且由于没有人等待邮件被接收，它只是一个非阻塞的消息。（有各种内置邮箱，包括有界和优先级。实际上，我们也可以自己构建一个）

3.故障转移

想象一下，这3位教师来自三个不同的部门 - 历史，地理和哲学。

历史老师回复过去的一个事件，地理老师发送一个有趣的地方和哲学老师，一个引用。每个学生都会向每位老师发送信息并获得回复。学生并不关心部门中的哪位老师发回答。如果有一天老师生病了怎么办？必须至少有一位老师处理来自该部门的邮件。在这种情况下，该部门的另一名教师会加强并完成工作。

注意事项：

1. 可能会有一群演员做不同的事情。

2. 一个Actor可以做一些导致异常的事情。它本身无法恢复。在这种情况下，新的Actor可以created代替旧的Actor 。或者，Actor可以忽略该特定消息并继续其余消息。这些被称为指令，我们稍后会讨论它们。

4.多任务处理

如果学生要求，我们假设每位教师也通过邮件发送考试成绩。类似地，Actor可以type轻松地处理多个消息。

5.链接

如果学生只想获得一个最终的合并琐事邮件而不是三个邮件怎么办？

我们也可以用Actors做到这一点。我们可以将教师链接为一个层次结构。我们稍后会谈到主管，并在谈论期货时重新审视同样的想法。

按照Mohan的要求，让我们尝试使用Actor模型中的组件映射类比组件。

学生和老师成为我们的Actors。电子邮件收件箱成为Mailbox组件。请求和响应无法修改。它们是immutable物体。最后，MessageDispatcherActor中的组件管理邮箱并将邮件路由到相应的邮箱Mailbox。

足够的谈话，让我们做一些代码....

转自:https://rerun.me/2014/09/11/introducing-actors-akka-notes-part-1/