アクター

アクターのクラスを定義する

アクターは Actor という基本traitを拡張することで実装することができます。また、ここで:meth:`receive`というメソッドを実装する必要があります。:meth:`receive`というメソッドはcase文の塊で(この型は`PartialFunction[Any, Unit]``です)、Scalaのパターンマッチングを使ってアクターがどのようなメッセージを処理できるかということとそのメッセージがどのように処理されるかということを定義します。

以下はこのサンプルコードです。

import akka.actor.Actor
import akka.actor.Props
import akka.event.Logging

class MyActor extends Actor {
  val log = Logging(context.system, this)

  def receive = {
    case "test" => log.info("received test")
    case _      => log.info("received unknown message")
  }
}

Akkaのアクターの``receive``メッセージループは網羅的であるということに注意してください。これはErlangやScala言語組み込みのアクターとは異なっています。つまり受け取ることのできる全てのメッセージについてのパターンマッチを書く必要があり、未知のメッセージを処理したい場合はデフォルトのcaseを書かなければいけません。これを行わなかった場合は ``ActorSystem``の``EventStream``に`akka.actor.UnhandledMessage(message, sender, recipient)``が発行されます。

また、振る舞いの戻り値の型が``Unit``であることにも注意してください。アクターが受け取ったメッセージに対して応答を返す場合、後で説明するようにこれを明示的に行う必要があります。

:meth:`receive`メソッドの結果は部分関数であり、アクターの"初期の振る舞い"とみなされます。アクターが生成された後でどのように振る舞いを変えるかということについての詳しい情報は`Become/Unbecome`_を参照してください。

Props

:class:`Propsはアクターを生成するときのオプションを指定するための設定クラスです。このクラスのインスタンスは不変なので気軽に共有することができるアクターを生成するためのレシピと考えることができます。また、このレシピにはデプロイに関係した情報(例えばどのdispatcherを使うかとかいったもの)も含めることができます。

import akka.actor.Props

val props1 = Props[MyActor]
val props2 = Props(new ActorWithArgs("arg")) // careful, see below
val props3 = Props(classOf[ActorWithArgs], "arg") // no support for value class arguments

二つ目のやり方は生成する:class:`Actor`にどのように引数を渡すかということを例示していますが、後で説明するように、アクターの外側のみで用いるべきやり方です。

最後のやり方はアクターのコンストラクタに引数を渡す場合にどのようなコンテクストでも使うことができるやり方です。Propsオブジェクトの中でどのコンストラクタを用いるべきかということを調べて、適当なコンストラクタが見つからなかった場合や複数のコンストラクタにマッチしてしまった場合には:class:IllegalArgumentException となってしまいます。

// NOT RECOMMENDED within another actor:
// encourages to close over enclosing class
val props7 = Props(new MyActor)

case class MyValueClass(v: Int) extends AnyVal

class ValueActor(value: MyValueClass) extends Actor {
  def receive = {
    case multiplier: Long => sender() ! (value.v * multiplier)
  }
}
val valueClassProp = Props(classOf[ValueActor], MyValueClass(5)) // Unsupported

class DefaultValueActor(a: Int, b: Int = 5) extends Actor {
  def receive = {
    case x: Int => sender() ! ((a + x) * b)
  }
}

val defaultValueProp1 = Props(classOf[DefaultValueActor], 2.0) // Unsupported

class DefaultValueActor2(b: Int = 5) extends Actor {
  def receive = {
    case x: Int => sender() ! (x * b)
  }
}
val defaultValueProp2 = Props[DefaultValueActor2] // Unsupported
val defaultValueProp3 = Props(classOf[DefaultValueActor2]) // Unsupported

object DemoActor {
  /**
   * Create Props for an actor of this type.
   *
   * @param magicNumber The magic number to be passed to this actor’s constructor.
   * @return a Props for creating this actor, which can then be further configured
   *         (e.g. calling `.withDispatcher()` on it)
   */
  def props(magicNumber: Int): Props = Props(new DemoActor(magicNumber))
}

class DemoActor(magicNumber: Int) extends Actor {
  def receive = {
    case x: Int => sender() ! (x + magicNumber)
  }
}

class SomeOtherActor extends Actor {
  // Props(new DemoActor(42)) would not be safe
  context.actorOf(DemoActor.props(42), "demo")
  // ...
}

object MyActor {
  case class Greeting(from: String)
  case object Goodbye
}
class MyActor extends Actor with ActorLogging {
  import MyActor._
  def receive = {
    case Greeting(greeter) => log.info(s"I was greeted by $greeter.")
    case Goodbye           => log.info("Someone said goodbye to me.")
  }
}

Propsを使ったアクターの生成

アクターは:class:`Props`のインスタンスを:class:`ActorSystem`や:class:`ActorContext`が持っている:meth:`actorOf`というファクトリメソッドに渡すことで生成できます。

import akka.actor.ActorSystem

// ActorSystem is a heavy object: create only one per application
val system = ActorSystem("mySystem")
val myActor = system.actorOf(Props[MyActor], "myactor2")

:class:`ActorSystem`を使うとトップレベルのアクターを生成できます。トップレベルのアクターはアクターシステムが提供しているガーディアンアクターによって監視されます。一方でコンテクストから生成したアクターはそのアクターの子アクターになります。

class FirstActor extends Actor {
  val child = context.actorOf(Props[MyActor], name = "myChild")
  // plus some behavior ...
}

子供から孫といった階層を作るようにしてください。そのようにすることでアプリケーションの論理的なエラー処理の構造を作ることができます。詳しくは:ref:`actor-systems`を参照してください。

:meth:`actorOf`を呼ぶことで:class:`ActorRef`のインスタンスを得ることができます。:class:`ActorRef`はアクターのインスタンスとつながっていて、アクターと対話するための唯一の手段となります。:class:`ActorRef`は不変でそれが表現しているアクターと一対一の関係を持っています。:class:`ActorRef`は永続化可能なのでネットワークを介することができます。つまり、シリアライズしたインスタンスをリモートのホストに送信した場合、元のノードのアクターをネットワークを超えて表現することができます。

nameパラメータはオプションですがアクターには名前を与えた方がよいでしょう。なぜなら、アクターの名前はログメッセージでアクターを識別するために用いるからです。アクターの名前は空文字や"$"から始まる文字列は許可されていませんが、そうした名前がURLにエンコードされた文字には含まれることがあります。(例えば、"%20"は空白文字です。)もじ与えられた名前が既に同じ親を持つ他の子アクターが利用していた場合、:class:`InvalidActorNameException`がスローされます。

アクターは生成されたら非同期に自動的に開始されます。

class Argument(val value: String) extends AnyVal
class ValueClassActor(arg: Argument) extends Actor {
  def receive = { case _ => () }
}

object ValueClassActor {
  def props1(arg: Argument) = Props(classOf[ValueClassActor], arg) // fails at runtime
  def props2(arg: Argument) = Props(classOf[ValueClassActor], arg.value) // ok
  def props3(arg: Argument) = Props(new ValueClassActor(arg)) // ok
}

依存性の注入

アクターがコンストラクタで引数を受け取る場合、`すでに述べたように`__それは:class:`Props`の生成の中で利用する必要があります。しかし、ファクトリメソッドを用意していたとしても直接コンストラクタを使うケースがあります。例えば依存性の注入を行うフレームワークがコンストラクタの引数を調べる場合です。

import akka.actor.IndirectActorProducer

class DependencyInjector(applicationContext: AnyRef, beanName: String)
  extends IndirectActorProducer {

  override def actorClass = classOf[Actor]
  override def produce =
    // obtain fresh Actor instance from DI framework ...
}

val actorRef = system.actorOf(
  Props(classOf[DependencyInjector], applicationContext, "hello"),
  "helloBean")

依存性の注入のためのテクニックや依存性注入を行うフレームワークとの統合については`Using Akka with Dependency Injection <http://letitcrash.com/post/55958814293/akka-dependency-injection>`_ guidelineやLightbend Activatorの中の`Akka Java Spring <http://www.lightbend.com/activator/template/akka-java-spring>`_ tutorialにより詳しい情報があります。

Inbox

アクターの外側のコードからアクターと通信をする場合、``ask``パターン(後で出てきます)を使うのが一つの方法ですが、それを使えない場合が二つあります。一つは複数のメッセージを受け取るような場合(例えば通知サービスとして実装されている:class:`ActorRef`を購読する場合)で、もう一つはActorのライフサイクルをwatchしている場合です。こういった場合のために:class:`Inbox`というクラスが用意されています。

このコードでは:class:`Inbox`から:class:`Inbox`への暗黙的な変換が行われています。つまりこの例ではsenderへの参照は暗黙的に:class:`Inbox`に対するものになります。このようにすることで最後の行に書かれているようなやり方で応答を受け取ることができます。アクターをwatchする方法も簡単です。

アクターのライフサクル

アクターシステムにおけるパスは生存しているアクターによって占有されている"場所"を表現しています。始めは(システムによって初期化されたアクターを除き)パスは空になっています。 actorOf() を呼びだすと Prop で表現されたアクターの*インカーネーション*が与えられたパスに生成されます。アクターのインカーネーションはパスと UID によって識別されます。再起動が行われたときには Actor のインスタンスは置き換えられますが、インカーネーションの方は置き換えられないので UID は同じものになります。

アクターのインカーネーションのライフサイクルはアクターが停止した時に終わります。この時、これに対応したライフサイクルの終了イベントが呼ばれ、これを watch しているアクターに停止が通知されます。インカーネーションが停止したのち、インカーネーションのパスは再び actorOf() を使って再利用することができるようになります。この場合新しいインカーネーションの名前は前のものと同じですがUIDは別のものになります。アクターは自分自身や他のアクター、あるいは``ActorSystem``によって停止されることがあります。(:ref:`stopping-actors-scala`を参照)

``ActorRef``はただ単に与えられたパスを表現しているのではなくいつでもインカーネーション(パスとUID)を表現しています。つまりアクターを停止して同じ名前のアクターを生成した場合、新しく生成した``ActorRef``は古いインカーネーションでなく新しいインカーネーションを指しています。

一方で ActorSelection はパスを示していて(ワイルドカードを使った場合は複数のパスを指します。)、現在そのパスを持っているのがどのインカーネーションなのかを完全に識別することができます。このため ActorSelection を watch することはできません。パスに存在するインカーネーションを watch するためには、ActorSelection に対して Identity メッセージを送信し ActorSelection から応答として ActorIdentity を受け取り、その中に含まれる正しい参照(actorSelection-scala`を参照)を使って現在のインカーネーションの ``ActorRef` を解決します。 ActorSelection が持つ resolveOne を使うとパスにマッチした ActorRef の Future が戻されるので同じようなことができます。

ライフサイクルの監視、DeathWatch

他のアクターの停止を知るために(例えば、永久に停止された場合や一時的ではない障害によって再起動された場合など)、アクターは他のアクターが停止時に発する Terminated メッセージを受け取るようにすることができます。(Stopping Actors`_も参照のこと)この機能はアクターシステムの :class:`DeathWatch というコンポーネントによって提供されています。

モニターを登録するのは簡単です。

import akka.actor.{ Actor, Props, Terminated }

class WatchActor extends Actor {
  val child = context.actorOf(Props.empty, "child")
  context.watch(child) // <-- this is the only call needed for registration
  var lastSender = context.system.deadLetters

  def receive = {
    case "kill" =>
      context.stop(child); lastSender = sender()
    case Terminated(`child`) => lastSender ! "finished"
  }
}

Terminated メッセージは登録や停止がどのような順番で起きたかとは独立して生成されることに注意してください。典型的な例として、監視を行うアクターは例え監視の登録を行った時点ですでに監視対象のアクターが停止されていたとしても Treminated メッセージを受け取ることになります。

監視の登録を複数回行うことが必ずしも複数のメッセージを作ることになるわけではありませんが、こうしたメッセージを正確に一度受け取ることができる保障はありません。監視対象のアクターの停止メッセージが作られてキューに入ってから、このメッセージが処理される前に他のところで登録が行われたら、二つ目のメッセージがキューに入ります。何故なら既に停止したアクターの監視を登録すると、直ちに: class:Terminated が生成されるためです。

同じようなことが他のアクターの生存監視を context.unwatch(target) を使ってやめた場合にも起こりえます。これは例え Terminated メッセージがメールボックスに入っていたとしても、unwatch`の呼び出しの後には監視を停止したアクターの :class:`Terminated メッセージは処理されないためです。

Start Hook

アクターが正しく起動すると、 preStart というメソッドが呼び出されます。

override def preStart() {
  child = context.actorOf(Props[MyActor], "child")
}

このメソッドはアクタがーが初めに生成されたときに呼び出されます。アクターが再起動したときには postRestart のデフォルトの実装がこのメソッドの呼び出しを行いますが、このメソッドをオーバーライドすることによって初期化のコードを一度だけ呼び出されるようにするのか、再起動のたびに呼び出されるようにするのかを選択することができます。アクターのコンストラクタの中の初期化コードはアクターが生成された時や再起動したときに常に呼び出されます。

Restart Hook

全てのアクターは、例えば他のアクターによるエラー処理のストラテジーに紐づくことによって監視されています。アクターがメッセージを処理しているときに例外をスローした場合は再起動が行われます。(スーパービジョン と モニタリング を参照)この再起動は上記に挙げたフック処理のトリガになります。

1. 古いアクターには preRestart の中で再起動の原因となった例外と例外を引き起こしたメッセージが通知されます。後者のメッセージは、例えばsupervisorが例外を補足せずにそれより上位のsupervisorに再起動された場合やアクターが兄弟関係にあるアクターの障害によって再起動された場合など、再起動の原因となったのがメッセージの処理ではない場合には　None が受け渡されます。メッセージが受け渡された場合には、メッセージのsenderもいつもと同じやり方で取得することができます。(これは、``sender``の呼び出しを行うことでできます)

   このメソッドは新しいアクターのインスタンスなどへの引き継ぎのためにクリーンアップを行うのにもっともよい場所です。デフォルトの実装では全ての子アクターを停止して postStop を呼び出すようになっています。

2. 新しいインスタンスを生成するために actorOf の呼び出し時から引き継いだ初期化のファクトリを利用します。

3. 新しく生成したアクターの postRestart に再起動の原因となった例外を受け渡して呼び出します。デフォルトの実装では preStart の呼び出しを行って通常のアクターの開始と同じように振る舞います。

アクターの再起動では実際のアクターのオブジェクトが入れ替わるだけです。再起動がメールボックの内容に影響を及ぼすことはないので、メッセージの処理は :metho:`postRestart` の処理が終わった後に再開されます。例外の原因となったメッセージを再び受け取ることはありません。再起動中にアクターが受け取ったメッセージは通常メールボックスには入りません。

Stop Hook

アクターが停止した後には、そのアクターの postStop フックが呼び出されるので、これを使って他のサービスからこのアクターを登録解除するといった処理を行うようにします。ここのフックはこのアクターに対するメッセージのキューイングが利用できなくなってから呼び出されることが保障されています。停止されたアクターに送信したメッセージは ActorSystem の deadLetters にリダイレクトされるようになります。

Tell: Fire-forget

メッセージを送る場合、こちらの方が好ましい手段です。メッセージを待つようなブロッキングがありません。この手段を用いることで並列性最大限に生かし、スケーラビリティを得ることができます。

actorRef ! message

Actorの中で呼びだした場合、送信側のアクターの参照が暗黙的にメッセージと一緒に受け渡され、受信側のアクターが sender():ActorRef というメンバーメソッドを使ってこれを利用できます。メッセージを受け取ったアクターはこれを使って、 sender() ! replyMsg という形で元の送信者に応答を返すことができます。

アクター ではない インスタンスから呼び出した場合、デフォルトでは送信者は deadLetters のアクターの参照になります。

Ask: Send-And-Receive-Future

ask パターンはアクターだけではなくfutureも含むパターンです。よって ActorRef のメソッドとしてではなくパターンとして使う形で提供されています。

import akka.pattern.{ ask, pipe }
import system.dispatcher // The ExecutionContext that will be used
final case class Result(x: Int, s: String, d: Double)
case object Request

implicit val timeout = Timeout(5 seconds) // needed for `?` below

val f: Future[Result] =
  for {
    x <- ask(actorA, Request).mapTo[Int] // call pattern directly
    s <- (actorB ask Request).mapTo[String] // call by implicit conversion
    d <- (actorC ? Request).mapTo[Double] // call by symbolic name
  } yield Result(x, s, d)

f pipeTo actorD // .. or ..
pipe(f) to actorD

一般的によく使う組み合わせなので、このサンプルコードでは ask と pipeTo というパターンを一緒に使っています。上記のコードは全てノンブロッキングで非同期だということに注目してください。 ask は :class:Future` を作りますが、for内包表記を使って3つのFutureを組み合わせて別の新しいFutureに合成しています。pipeTo``　はFutureに ``onComplete ハンドラを作って Result に集約された結果を他のアクターに受け渡します。

ask を使うとメッセージは tell を使って受信側のアクターに送信され、 受信側のアクターは Future として値を返すために sender() ! reply を使って応答を返さなければいけません。 ask を実行すると応答を処理するための内部的なアクターが生成されますが、資源がリークさせないように一定時間を経過したらそれが破棄されるようタイムアウトを設ける必要があります。以下の詳細をご覧ください。

try {
  val result = operation()
  sender() ! result
} catch {
  case e: Exception =>
    sender() ! akka.actor.Status.Failure(e)
    throw e
}

アクターがFutureの処理を完了しなかった場合、タイムアウト経過後に AskTimeoutException を返して有効期限切れになります。タイムアウトは次のような優先順位で取得されます。

1. 次のように明示的に与えられた場合

import scala.concurrent.duration._
import akka.pattern.ask
val future = myActor.ask("hello")(5 seconds)

2. akka.util.Timeout 型の暗黙的引数

import scala.concurrent.duration._
import akka.util.Timeout
import akka.pattern.ask
implicit val timeout = Timeout(5 seconds)
val future = myActor ? "hello"

Futureの結果をどのように待つかといったことやFutureに対する操作については future-scala を参照してください。

onComplete や onSuccess 、 onFailure といった Future のメソッドはFutureの処理が完了した時にブロックすることなく通知を受け取るためのコールバックとして利用することができます。

メッセージの転送

あるアクターが別のアクターへメッセージを転送することができます。これはメッセージが'仲介者'を経由した後でも元の送信者のアドレスや参照が維持されるということです。これはアクターをルーターやロードバランサ、レプリケイターといった用途で使う場合、便利です。

target forward message

毒薬

アクターに akka.actor.PoisonPill メッセージを送ることもできます。このメッセージが処理されると、アクターは停止します。 PoisonPill は通常のメッセージとしてエンキューされ、すでにメールボックスにキューイングされているメッセージの後に処理されます。

グレースフルな停止

gracefulStop は、終了を待つ必要がある場合や、いくつかのアクタの順序付けられた終了を構成する必要がある場合に便利です。

import akka.pattern.gracefulStop
import scala.concurrent.Await

try {
  val stopped: Future[Boolean] = gracefulStop(actorRef, 5 seconds, Manager.Shutdown)
  Await.result(stopped, 6 seconds)
  // the actor has been stopped
} catch {
  // the actor wasn't stopped within 5 seconds
  case e: akka.pattern.AskTimeoutException =>
}

object Manager {
  case object Shutdown
}

class Manager extends Actor {
  import Manager._
  val worker = context.watch(context.actorOf(Props[Cruncher], "worker"))

  def receive = {
    case "job" => worker ! "crunch"
    case Shutdown =>
      worker ! PoisonPill
      context become shuttingDown
  }

  def shuttingDown: Receive = {
    case "job" => sender() ! "service unavailable, shutting down"
    case Terminated(`worker`) =>
      context stop self
  }
}

gracefulStop() が正常に返されると、アクターの postStop() フックが実行されます: postStop() の終了と gracefulStop() の完了の間には順次呼び出しの隙間があります。

上記の例では、カスタムの Manager.Shutdown メッセージがターゲットのアクターに送信され、アクターを停止するプロセスが開始されます。 これを実現するのに PoisonPill を使うこともできますが、ターゲットのアクターを停止する前に他のアクターとのやり取りを行う可能性がわずかながらあります。 単純なクリーンアップのタスクは postStop で処理できます。

更新

Akkaは、実行時にアクターのメッセージループ(例：その実装)をホットスワップすることをサポートしています。これを行うためには、アクターの中から `` context.become`` メソッドを呼び出します。 ：meth： become は、新しいメッセージハンドラの実装となる ` PartialFunction [Any、Unit] ` を受け取ります。 ホットスワップされたコードはスタックに保持され、プッシュしたりポップしたりすることができます。

アクターの振る舞いをホットスワップするためには become を使用します。

class HotSwapActor extends Actor {
  import context._
  def angry: Receive = {
    case "foo" => sender() ! "I am already angry?"
    case "bar" => become(happy)
  }

  def happy: Receive = {
    case "bar" => sender() ! "I am already happy :-)"
    case "foo" => become(angry)
  }

  def receive = {
    case "foo" => become(angry)
    case "bar" => become(happy)
  }
}

：meth： become`メソッドの変種は便利で例えば有限状態マシン (FSM、この例は、`Dining Hakkers`を参照してください_) を実装するなど、さまざまな目的に役立ちます。 有限状態マシンは現在の動作(つまり動作スタックの先頭)を置き換えます。つまり、：meth： `unbecome を使わなくても、常に次の動作が明示的に決まります。

：meth： become のもう一つの使い方として、動作スタックの先頭を置き換えずにスタックの先頭に追加するというものがあります。 この場合、「ポップ」操作の数(すなわち ：meth： unbecome)が長期的に「プッシュ」の数に一致するように注意する必要があります。そうでなければ、メモリリークが発生します(この動作はデフォルトではないのはこれが理由です)。

case object Swap
class Swapper extends Actor {
  import context._
  val log = Logging(system, this)

  def receive = {
    case Swap =>
      log.info("Hi")
      become({
        case Swap =>
          log.info("Ho")
          unbecome() // resets the latest 'become' (just for fun)
      }, discardOld = false) // push on top instead of replace
  }
}

object SwapperApp extends App {
  val system = ActorSystem("SwapperSystem")
  val swap = system.actorOf(Props[Swapper], name = "swapper")
  swap ! Swap // logs Hi
  swap ! Swap // logs Ho
  swap ! Swap // logs Hi
  swap ! Swap // logs Ho
  swap ! Swap // logs Hi
  swap ! Swap // logs Ho
}

Scalaのアクターは、メモリを誤ってリークすることなくネストされた受信を行います。

以下の ネスとしない受信の例 <@github@/akka-docs/rst/scala/code/docs/actor/UnnestedReceives.scala> を参照してください。

メッセージへの影響

メッセージの処理中に例外がスローされた場合(つまり、メールボックスから取り出され、現在の動作に引き渡されていた場合)、このメッセージは失われます。それがメールボックスに戻されないということを理解しておくことが重要です。したがって、メッセージの処理を再試行したい場合は、例外をキャッチして自分で処理し、フローを再試行する必要があります。システムがライブロックしないようにするため、再試行回数に制限を書けるようにしてください(処理を行わないのにCPUサイクルを多く消費してしまいまう)。 PeekMailbox pattern を用いるという手もあります。

メールボックスへの影響

メッセージの処理中に例外がスローされても、メールボックスには何の影響もありません。アクターが再起動すると、同じメールボックスが利用されます。メールボックスの中のすべてのメッセージもそこにあります。

アクターへの影響

アクター内のコードが例外をスローすると、そのアクターは中断され、スーパーバイザーの処理が開始します(：ref： supervision を参照してください)。アクターはスーパーバイザーの決定に従って、(何も起きなかったのと同じように)レジュームしたり、再起動したり(内部状態を一掃してゼロから開始します)、停止したりします。

コンストラクタを使った初期化

コンストラクタを使った初期化には様々な利点があります。まず第一に、アクターインスタンスの存続期間中に変化しない状態を格納するために ``val``フィールドを使用することができるようになり、アクターの実装がより堅牢になります。コンストラクタはアクターのインカネーションごとに呼び出されるため、アクタの内部は常に適切な初期化が行われたとみなすことができます。しかし、この方法の欠点でもあります。再起動時に内部の再初期化を避けたい場合があるためです。たとえば、再起動をまたいで子アクターを保持すると便利なことがあります。次のセクションでは、このケースのパターンを示します。

preStart による初期化

アクターの preStart() メソッドは、最初のインスタンスの初期化中、つまり ActorRef の作成時に一度だけ直接的に呼び出されます。再起動の場合、 `` preStart()``は `` postRestart()``から呼び出されるため、オーバーライドしないと、すべてのインカネーションで ``preStart()``が呼び出されます。しかし、 ``postRestart()``をオーバーライドすることで、この動作を無効にし、 ``preStart()``への呼び出しが1つしかないことを保証することができます。

このパターンの便利な使い方の1つは、再起動時に子プロセスの新しい ActorRefs の作成を無効にすることです。これは preRestart() をオーバーライドすることで実現できます：

override def preStart(): Unit = {
  // Initialize children here
}

// Overriding postRestart to disable the call to preStart()
// after restarts
override def postRestart(reason: Throwable): Unit = ()

// The default implementation of preRestart() stops all the children
// of the actor. To opt-out from stopping the children, we
// have to override preRestart()
override def preRestart(reason: Throwable, message: Option[Any]): Unit = {
  // Keep the call to postStop(), but no stopping of children
  postStop()
}

子アクターはまだ 再起動しています が、新しい ``ActorRef``は作成されないということに注目してください。子アクターに同じ原則を再帰的に適用して、 ``preStart()``メソッドがrefの作成時にのみ呼び出されるようにすることができます。

さらに詳しい情報は リスタートが意味するもの を参照してください。

メッセージパッシングによる初期化

たとえば、循環依存が存在する場合など、アクターの初期化に必要なすべての情報をコンストラクタに渡すことが不可能な場合があります。この場合、アクターは初期化メッセージをリッスンし、アクターの初期化後の状態と初期化前の状態をエンコードするために become() または有限ステートマシン状態による遷移を使用する必要があります。

var initializeMe: Option[String] = None

override def receive = {
  case "init" =>
    initializeMe = Some("Up and running")
    context.become(initialized, discardOld = true)

}

def initialized: Receive = {
  case "U OK?" => initializeMe foreach { sender() ! _ }
}

アクターが初期化される前にメッセージを受けとる場合、初期化が完了するまでメッセージを保存し、アクターが初期化された後にメッセージを再生する Stash という便利なツールがあります。