Akka Classic Actor的sender()运行时返回deadLetters单测正常问题

• 首先明确Actor.sender()的实现本质：Akka Classic将当前处理消息的发送者引用存在线程局部变量（ThreadLocal）中，只有当前正在处理消息的Actor调度线程才能读取到正确值。一旦消息处理流程结束，或者代码执行切换到其他线程，ThreadLocal的值会被清空/覆盖，此时调用sender()就会返回deadLetters。
• 生产环境行为符合预期：你在Future回调中调用sender()，生产环境下Future使用的是异步ExecutionContext，回调逻辑会提交到其他线程池执行，此时原Actor处理线程已经完成当前消息的处理流程，ThreadLocal中的sender值已被清除，因此拿到的是deadLetters。
• 单元测试行为不一致的核心原因：Akka TestKit默认使用CallingThreadDispatcher（调用线程调度器），这是一个同步调度器，提交给它的所有任务包括Future回调都会在当前调用线程（也就是Actor处理消息的原线程）中同步执行。此时消息处理流程还未结束，ThreadLocal中的sender值还未被清除，因此能拿到正确的发送者引用。部分场景下如果你测试配置用了单线程池且Future执行速度足够快，也会碰巧复用原线程拿到正确值，但这属于不可靠的巧合。

核心原则：只要在Actor逻辑中涉及异步回调（Future、自定义线程操作等），必须在触发异步操作前将sender()捕获为局部变量，后续直接引用该局部变量即可，不要在异步闭包内调用sender()。
示例代码修改如下：

class MyActor extends Actor {
  private def throwError(replyTo: ActorRef) = {
    replyTo ! MyErrorMessage()
    throw new Exception()
  }

  private def myFutureMethod(args: SomeType, replyTo: ActorRef): Future[Done] = {
    for {
       // 原有业务逻辑
    } yield {
      if (/* 原有逻辑判断 */)
        throwError(replyTo)
      else
        Done
    }
  }

  override def stepReceive = {
    case MyMessage(args) => 
      // 提前捕获sender，不要传入Future闭包内再调用sender()
      val replyTo = sender()
      myFutureMethod(args, replyTo)
  }
}

• 打印执行线程ID：分别在生产环境和单元测试的sender()调用处打印当前线程ID，对比Actor接收消息入口处的线程ID，即可确认是否发生了线程切换。
• 强制测试使用异步调度器：在单元测试的Actor配置中指定使用生产环境同款异步调度器，即可复现生产环境的deadLetters问题，验证逻辑正确性。
• 打印sender的路径：分别在Actor接收消息入口、Future回调中打印sender().path，可以直观看到值的变化。

内容的提问来源于stack exchange，提问作者Samuel Labrador