原文：http://rerun.me/2014/10/21/akka-notes-child-actors-and-path/
Actor是完全的继承结构。你创建的任何Actor肯定都是一个其他Actor的child。
让我们分析下：
PATH
我们用ActorSystem.actorof创建一个ActorRef并打印出他的path
val actorSystem=ActorSystem("SupervisionActorSystem")
val actorRef=actorSystem.actorOf(Props[BasicLifecycleLoggingTeacherActor])
println (actorRef.path) // (prints) akka://SupervisionActorSystem/user/$a 可以看到，一个path看起来很像是文件系统中的一个文件路径。
- 这里的akka是固定的，因为这些都是Akka Actor的地址 - 与file://和http://前缀差不多（跟协议没啥关系）
- SupervisionActorSystem就是你创建的ActorSystem的名字。
- user我们下节再说。
- $a是系统为你生成出来的Actor的名字。你对操作系统给你随机生成的文件名怎么看？很明显是人都不喜欢，因为你之后还要用这个名字。所以，让我们给他一个有意义的名字：
val actorRef=actorSystem.actorOf(Props[BasicLifecycleLoggingTeacherActor], "teacherActor")
println (actorRef.path) // (prints) akka://SupervisionActorSystem/user/teacherActor现在这个路径（path）看起来差不多了。
CHILD ACTORS
跟从ActorSystem里面创建的顶级actor类似，我们也可以给ActorContext创建child actor。事实上， Actor的容错能力很大程度上就是靠使用Actor的继承层次和一个parent管理child actor的生命周期的方式。
现在假设你又一个TeacherSupervisor并且你打算创建一个TeacherActor来作为Supervisor的child，可以用ActorContext.actorof来代替使用ActorSystem.actorof:
class TeacherSupervisor extends Actor with ActorLogging {
val teacherActor=context.actorOf(Props[TeacherActor], "teacherActor")
...
...基本上，在任何应用里，不像顶层actor，你会创建一堆的child actor - 这意思就是与调用actorSystem.actorof不同，你会调用一堆actorContext.actor
你会注意到child actor的path是akka://SupervisionActorSystem/user/teacherSupervisor/teacherActor，看起来跟给父目录创建一个子目录是一样的。
你什么时候开始创建子Actor？
在你的任务是由子任务或多个子任务组成的时候你就应该创建一个子actor了。在你执行的子任务是一个易错的时候，你想要隔离他（这样如果错了，你能恢复他）的时候你也需要创建一个子actor。当task之间没有父子关系时，你千万别创建子actor。
并且，还可以让子actor创建自己的子actor来代理他们自己的子任务。Actor的创建成本很低但产出却很高（我们在谈supervision的时候可以看到这个）
现在那个PATH中的USER是什么？
作为一个对比，我把ActorSystem比拟成一个Unix文件系统 - 有一个/root目录，还有其他的/etc,/usr,/bin和其他目录。
ActorSystem跟那个差不多。他创建一些顶层Actor - 最重要根Actor就是根目录/， user Actor就是/usrr目录，一个system Actor就是一个/system目录。（还有一个/deadLetters来代表DeadLetterActorRef。我们在上一篇里面看到过）
ActorSystem内组合了三个Actor（从ActorRefProvider）。他们是ActorSystem创建的所有actor的根actor。
- systemGuardian actor - 所有在/system下的actor的根
- guardian actor - 所有/user下actor的根
- rootGuardian Actor - systemGuardian和**userGuardian**actor
的根
/**
* Reference to the supervisor of guardian and systemGuardian; ....
*/
def rootGuardian: InternalActorRef
/**
* Reference to the supervisor used for all top-level user actors.
*/
def guardian: LocalActorRef
/**
* Reference to the supervisor used for all top-level system actors.
*/
def systemGuardian: LocalActorRef
/user(aka) user guardian
任何你在自己程序中像StudentActor或TeacherActor用ActorSystem的actof方法来创建的Actor都直接在/user。这就是之前teacherActor的路径是/user/teacherActor的原因。
/system(aka) system guardian
当userGuardian死的时候system guardian会将自己关闭。当userGuardian关闭时这是合乎常理的， 他下面所有的业务actor都停掉了所以所有的管理员actor都需要一样停掉。
我们能看到System Actor被创建在两个地方 - 意思是在*/system继承关系下的actor。
- 像我们之前看到的，所有发给一个已经终结掉的Actor的消息都会被转发给一个内部Actor（DeadLetterActor）的邮箱。DeadLetter Actor把每个消息包装成DeadLetter*然后发送给EventStream。另一个叫**DeadLetterListener的Actor消费所有的DeadLetter并且将其作为一个日志消息发送出去。现在，DeadLetterListener是一个在/system/deadLetterListener下的system Actor。
- 想想我们之前写的订阅了EventStream的日志消息的TestEventListener?他们也是System actor。事实上，所有的akka.logger都是作为System actor来创建的。
class TeacherTest extends TestKit(ActorSystem("UniversityMessageSystem", ConfigFactory.parseString("""akka.loggers = ["akka.testkit.TestEventListener"]""")))
...
...这个文档提到所有用配置文件配置的Actor都会在启动的时候被创建并部署到ActorSystem，躲在/system的保护伞下。当我找到有趣的地方再更新下这个。
/(aka)root guardian
像我们之前看到的，/下的Actor是user和system guardian的父 actor。
杂七杂八
技术上来讲，root actor也有个父actor。这个actor的唯一任务就是当root actor失败是关闭整个ActorSystem。因此他没有被算在Actor的继承结构里， Akka项目组叫他：
private[akka] val theOneWhoWalksTheBubblesOfSpaceTime: InternalActorRef = new MinimalActorRef {
...
文章来自微信平台「麦芽面包」（微信扫描二维码关注）。未经允许，禁止转载。