Akka源码分析-Actor发消息(续)
上一篇博客我们分析道mailbox同时也是一个forkjointask，run方法中，调用了processMailbox处理一定数量的消息，然后最终调用dispatcher的registerForExecution重新进行线程调度，达到循环处理邮箱消息的功能。接下来我们分析一下processMailbox函数的功能。
/**
* Process the messages in the mailbox
*/
@tailrec private final def processMailbox(
left: Int = java.lang.Math.max(dispatcher.throughput, 1),
deadlineNs: Long = if (dispatcher.isThroughputDeadlineTimeDefined == true) System.nanoTime + dispatcher.throughputDeadlineTime.toNanos else 0L): Unit =
if (shouldProcessMessage) {
val next = dequeue()
if (next ne null) {
if (Mailbox.debug) println(actor.self + " processing message " + next)
actor invoke next
if (Thread.interrupted())
throw new InterruptedException("Interrupted while processing actor messages")
processAllSystemMessages()
if ((left > 1) && ((dispatcher.isThroughputDeadlineTimeDefined == false) || (System.nanoTime - deadlineNs) < 0))
processMailbox(left - 1, deadlineNs)
}
}
上面是processMailbox的代码，很明显这是一个尾递归，它一次性处理dispatcher.throughput个消息，并在dispatcher.throughputDeadlineTime时间内退出此次递归。源码也比较简单，大致的处理过程就是：队列取出消息，调用actor的invoke函数，处理所有系统消息，如果还有剩余消息或者未达到时间长度限制，则继续下一条消息处理。
代码虽然简单，但有几个隐含的点，需要说明。这是一个尾递归，且在线程池分配的某个线程中执行，则可以确保，actor处理此次批量消息时，一定是在某一个线程中，不会出现并行的情况。且该函数处理完毕后，会再被线程池进行调度，则下一次的线程跟此次应该不同。另外处理完每一条消息后都会把系统消息处理完毕，也就是说系统消息的优先级非常高。
override final def run(): Unit = {
try {
if (!isClosed) { //Volatile read, needed here
processAllSystemMessages() //First, deal with any system messages
processMailbox() //Then deal with messages
}
} finally {
setAsIdle() //Volatile write, needed here
dispatcher.registerForExecution(this, false, false)
}
}
我们再回到run方法，会发现，没有对异常进行处理。也就是说如果处理用户消息或者系统消息出现异常时，依然会进入下一次调度。我们接下来看一下ActorCell的invoke代码。
//Memory consistency is handled by the Mailbox (reading mailbox status then processing messages, then writing mailbox status
final def invoke(messageHandle: Envelope): Unit = {
val influenceReceiveTimeout = !messageHandle.message.isInstanceOf[NotInfluenceReceiveTimeout]
try {
currentMessage = messageHandle
if (influenceReceiveTimeout)
cancelReceiveTimeout()
messageHandle.message match {
case msg: AutoReceivedMessage ⇒ autoReceiveMessage(messageHandle)
case msg ⇒ receiveMessage(msg)
}
currentMessage = null // reset current message after successful invocation
} catch handleNonFatalOrInterruptedException { e ⇒
handleInvokeFailure(Nil, e)
} finally {
if (influenceReceiveTimeout)
checkReceiveTimeout // Reschedule receive timeout
}
}
我们暂时先忽略对超时消息的处理，发现invoke最终调用了receiveMessage(msg)。
final def receiveMessage(msg: Any): Unit = actor.aroundReceive(behaviorStack.head, msg)
receiveMessage又转而调用了actor的aroundReceive方法，actor是什么呢？
private[this] var _actor: Actor = _ def actor: Actor = _actor protected def actor_=(a: Actor): Unit = _actor = a
通过定义我们知道这就是一个普通的Actor，追踪到这里终于调用了Actor特质的函数了，但仅仅调用了aroundReceive，而不是我们常见的receive函数。
/**
* INTERNAL API.
*
* Can be overridden to intercept calls to this actor's current behavior.
*
* @param receive current behavior.
* @param msg current message.
*/
@InternalApi
protected[akka] def aroundReceive(receive: Actor.Receive, msg: Any): Unit = {
// optimization: avoid allocation of lambda
if (receive.applyOrElse(msg, Actor.notHandledFun).asInstanceOf[AnyRef] eq Actor.NotHandled) {
unhandled(msg)
}
}
那就看看aroundReceive的源码喽。通过官方源码说明和代码分析，我们知道这里调用了我们最终定义的receive函数，如果receive没有处理该类型的消息，则调用unhandled。默认情况下unhandled应该会发送给deadletters。
/**
* User overridable callback.
* <p/>
* Is called when a message isn't handled by the current behavior of the actor
* by default it fails with either a [[akka.actor.DeathPactException]] (in
* case of an unhandled [[akka.actor.Terminated]] message) or publishes an [[akka.actor.UnhandledMessage]]
* to the actor's system's [[akka.event.EventStream]]
*/
def unhandled(message: Any): Unit = {
message match {
case Terminated(dead) ⇒ throw DeathPactException(dead)
case _ ⇒ context.system.eventStream.publish(UnhandledMessage(message, sender(), self))
}
}
在invoke方法中，还有一个函数的调用也不得不说：autoReceiveMessage。通过名字我们知道它应该是自动处理的消息，而不需要自己处理。哪些消息不需要我们处理呢？
def autoReceiveMessage(msg: Envelope): Unit = {
if (system.settings.DebugAutoReceive)
publish(Debug(self.path.toString, clazz(actor), "received AutoReceiveMessage " + msg))
msg.message match {
case t: Terminated ⇒ receivedTerminated(t)
case AddressTerminated(address) ⇒ addressTerminated(address)
case Kill ⇒ throw ActorKilledException("Kill")
case PoisonPill ⇒ self.stop()
case sel: ActorSelectionMessage ⇒ receiveSelection(sel)
case Identify(messageId) ⇒ sender() ! ActorIdentity(messageId, Some(self))
}
}
Terminated、AddressTerminated、Kill、PoisonPill、ActorSelectionMessage、Identify。怎么样这几个消息是不是比较眼熟呢。当然我们这里就不再展开分析了，不过读者如果对Terminated、AddressTerminated、Kill、PoisonPill几个消息的区别感兴趣的话，可以继续研究一下对应的处理过程。有些是抛异常，有些是调函数，还是有一些区别的。
另外在invoke方法中，还有一个字段我们也不应该忽略：currentMessage。通过其名称以及相关的代码逻辑，我们知道这仅仅是标志当前消息。那么它有什么用呢？
final def sender(): ActorRef = currentMessage match {
case null ⇒ system.deadLetters
case msg if msg.sender ne null ⇒ msg.sender
case _ ⇒ system.deadLetters
}
翻了一下源码，最终定位到以上代码。sender()是不是比较眼熟呢？currentMessage是为了给sender()返回对应的值的。不过有几点需要注意。currentMessage只是一个“临时”值，也就意味着sender()也会是一个“临时”值。临时的意思是在此次消息处理结束之后，对应的currentMessage会变化，sender返回的值也会变化。这也就是告诉读者，sender函数返回的值只有在此次消息处理过程中有效，且只在当前线程有效。如果消息处理时，出现了Future代码块，则在Future代码块内部，不要再调用sender函数！
补充：其实细心的读者一定会发现sender是一个闭包。简单来说闭包是一个函数，它的返回值取决于此函数之外声明一个或多个变量的值。sender的返回值取决于currentMessage变量。
invoke方法中还有一段代码同样很重要：handleNonFatalOrInterruptedException。这段代码逻辑比较简单，大概是先中止当前的消息处理，然后中止children的消息处理，最后发送一个系统消息给监督者（也就是父actor）。如果中止当前或children消息过程中也出现了异常，则就是stop所有子actor了。
final def handleInvokeFailure(childrenNotToSuspend: immutable.Iterable[ActorRef], t: Throwable): Unit = {
// prevent any further messages to be processed until the actor has been restarted
if (!isFailed) try {
suspendNonRecursive()
// suspend children
val skip: Set[ActorRef] = currentMessage match {
case Envelope(Failed(_, _, _), child) ⇒ { setFailed(child); Set(child) }
case _ ⇒ { setFailed(self); Set.empty }
}
suspendChildren(exceptFor = skip ++ childrenNotToSuspend)
t match {
// tell supervisor
case _: InterruptedException ⇒
// ➡➡➡ NEVER SEND THE SAME SYSTEM MESSAGE OBJECT TO TWO ACTORS ⬅⬅⬅
parent.sendSystemMessage(Failed(self, new ActorInterruptedException(t), uid))
case _ ⇒
// ➡➡➡ NEVER SEND THE SAME SYSTEM MESSAGE OBJECT TO TWO ACTORS ⬅⬅⬅
parent.sendSystemMessage(Failed(self, t, uid))
}
} catch handleNonFatalOrInterruptedException { e ⇒
publish(Error(e, self.path.toString, clazz(actor),
"emergency stop: exception in failure handling for " + t.getClass + Logging.stackTraceFor(t)))
try children foreach stop
finally finishTerminate()
}
}
到此为止，我们就把消息的处理过程分析完毕了。但这只是本地actor的大致处理逻辑，并不涉及remote和cluster的处理过程。还有dispatch对线程的调度也并没有深入分析，后面我会根据需要深入分析这些技术细节。
