今さらだけど JavaFX で非同期処理

Java JavaFX NetBeans

このエントリーは、JavaFX Advent Calendar 2017 の 6 日目です。

昨日は @planet-az さんの「簡単なミュージックプレーヤーを作ってみた」でした。

明日はこの記事を書いている現時点ではまだ空いてます。(^_^; きっと誰かが素敵な記事を投稿してくれると楽しみにしています。

今さらですが JavaFX の非同期処理を復習がてら簡単にみていきたいと思います。

では、次のようなプログラムを作ってみます。

1

long result = 1;

for (int i = 0; i < repeatProcessingNumber; i++) {

result += result;

初期値 1 で10回ループするプログラムです。

計算終了後は 1024 と結果を表示します。

これだけでは時間のかかる処理とはならないので

TimeUnit.MILLISECONDS.sleep(500);

とスレッドをスリープさせています。

プログラムの状態、計算中の値の表示やキャンセルなどのメッセージ表示、プログレスバーによるプログラムの進捗状態の可視化などを実装します。

思考停止状態でギナギナっと作ったプログラムは次のようなものです。

Warning! This code will make you headache.

You do not have to read it.

それではこのプログラムを実行してみましょう。

2

「START」 ボタンを押した瞬間プロブラムがフリーズしたようになりました。

そして暫くすると結果が表示されました。

3

これは駄目ですね。(>_<。)

プログラムがビジー状態で応答しなくなってしまっては使い物になりません。

進捗状態がわからないのは致命的です。

そして唐突に計算が終了してプログラムが完了する。

そう言えば遠い昔にこのような状態のプログラムが当たり前のように存在していたような気がする。

今の時代こんなのは絶対に許されません。

何がいけないのか?

それは時間のかかる処理を JavaFX アプリケーションスレッド上で行っているからです。

NetBeans のプロファイラで確認してみます。

4

JavaFX Application Thread タイムラインを見てください。

START ボタンを押した瞬間に時間のかかる処理(スレッドスリープ)が走ってます。(緑色から紫色に変わっているところ)

これでは UI の更新処理などはできませんね。

時間のかかる処理をしている間プログラムの応答は無くなり、ビジー状態のようになってしまいます。

つまり、時間のかかる処理用にスレッドをもう一つ起こせばこの問題は解決するはずです。

この問題を解決するのに最適な方法は javafx.concurrentパッケージを使用することです。

javafx.concurrent パッケージは、Worker インタフェースと、2つの具体的な実装である Task および Service クラスで構成されています。

Worker インタフェースは、バックグラウンドスレッド上の Worker オブジェクトの状態、進捗を監視可能なプロパティで公開しています。

状態は ReadOnlyObjectProperty<Worker.State> stateProperty で確認できます。

次のように Enum Worker.State で定義されています。

  • READY     Workerがまだ実行されておらず、実行の準備ができているか、またはWorkerが再初期化されたことを示します。
  • SCHEDULED   Workerの実行がスケジュールされているが、現在は実行中ではないことを示します。
  • RUNNING        このWorkerが実行中であることを示します。
  • SUCCEEDED   このWorkerが正常に完了しており、valueプロパティから読み取る準備ができている有効な結果があることを示します。
  • CANCELLED     このWorkerがWorker.cancel()メソッドによって取り消されたことを示します。
  • FAILED         通常は予期しない条件が発生したことによって、このWorkerが失敗したことを示します。

これらは JavaFX アプリケーションスレッドから使用できます。

Worker オブジェクトによって実行される処理の進捗は、totalWork、workDone、progress など、3つの異なるプロパティを通じて取得できます。

Worker オブジェクトの状態が変化するときに発生するイベントは WorkerStateEventクラスによって指定されます。

これは Task クラスと Service クラスの両方に EventTarget インタフェースが実装され状態イベントのリスニングがサポートされているからです。

今回は再利用の必要が無い Worker オブジェクトを生成するので Task クラスを利用します。

上記のように JavaFX の Task クラスは FutureTask クラスの完全に監視可能にした実装となっています。

この Task クラスを拡張しバックグラウンドスレッドで実行するロジックを実装します。

懐かしのSwingWorker クラスを思い出させてくれますね。(もう、ほとんど覚えてないけどね)

SwingWorker では doInBackground() メソッドにてバックグラウンドスレッドロジックを呼び出します。

JavaFX の場合は call() メソッドです。

doInBackground() メソッド、call() メソッドともにどちらも抽象メソッドなのでオーバーライドして使います。

call() メソッドは Task クラスが実行されるときに呼び出され、call() メソッドに実装されたバックグラウンドスレッドロジックを実行します。

つまり、仕組み的には SwingWorker とほとんど変わりはないので馴染みやすいかも知れません。

さて、JavaFX のために用意されたのにこれだけではあまり意味がありません。

この Task クラスの実行にあたり updateProgress() メソッド、updateMessage() メソッド、updateValue() メソッド、updateTitle() メソッドを呼び出すことができます。

これらを使用するとプログラムの状態、進捗状況、実行中の処理の結果の一部を返すなどを可視化できます。

ちょっと updateValue() メソッドの実装をみてみましょう。

呼び出しが JavaFX アプリケーションスレッドかそうでないかで分岐処理をおこなっています。

JavaFX アプリケーションスレッドからだったらそのまま値を更新します。

でなければ runLater()メソッドで javafx.application.Platform クラスの runLater(Runnable runnable) メソッドを呼び出して値を更新します。

何故なら、JavaFX Sceneグラフは、スレッドセーフではなく、JavaFXアプリケーションスレッドのみアクセスおよび変更できます。

これは Swing では javax.swing.SwingUtilities クラスの invokeLater(Runnable doRun) メソッドと同じようなものです。

JDK1.3 からは java.awt.EventQueue.invokeLater() を呼び出すように作られています。

このinvokeLater(Runnable doRun) メソッドはどのスレッドからも呼び出しが可能となっています。

javafx.application.Platform クラスの runLater(Runnable runnable) メソッドも任意のスレッドから呼び出し可能となっています。

updateProgress() メソッド、updateMessage() メソッド、updateValue() メソッド、updateTitle() メソッドの API ドキュメントには「このメソッドは、任意のスレッドから安全に呼び出すことができます。」と記載されています。

ちなみに updateValue() メソッドは JavaFX 8 からなので上記のようにラムダ式を使い綺麗に書かれています。

古くからある updateMessage() メソッドは次のように Java SE 7 の時代のコードのままとなっています。

このようなのを目にすると Java は開発者のために進化し続けている言語なんだなぁって感慨深いものがありますね。

SwingWorker のように publish() メソッド、process() メソッドなんてのは JavaFX には必要なくなってます。

このようにありがたい機能を標準で実装されている Task クラスですがさらに便利なプロパティを持っています。

これから先程のプログラムを改善するのにいくつかの Task クラスのプロパティを使用します。

それらプロパティは JavaFX のバインドという機能により快適に使用することが可能です。

JSR 295 Beans Binding と同じようなものです。

実際にどのように利用するかというと Task クラスの実行状態(Worker オブジェクト)のプロパティを利用して「START」ボタン、「CANCEL」ボタンの活性化、非活性化をおこないます。

また、バックグラウンドスレッド(Worker オブジェクト)の状態、計算結果の一部を返す処理、プログレスバーによるプログラムの進捗状態の表示もおこないます。

これらの対応を施したプログラムは次のようになります。

このプログラムの実行結果を見てみましょう。

5

ついでに NetBeans のプロファイラでバックグラウンドスレッドが生成されているのを確認しましょう。

6

pool-2-thread-1 がバックグラウンドスレッドとして起動されています。

これで JavaFX アプリケーションスレッドはイベント処理が可能となります。

画面が固まることなくバックグラウンドスレッドの状態、計算結果の一部(途中経過)、プログレスバーも表示されています。

また、「START」ボタン、「CANCEL」ボタンの活性化、非活性化もちゃんとできています。

まず、Task クラスをみていきましょう。

今回はcall() メソッドを実行するために java.util.concurrent の ExecutorService インタフェースを利用しました。

184行目です。

executorService.submit(task);

タスクをパラメータとして指定したスレッドの開始としては次の方法もあります。

Thread th = new Thread(task);
th.setDaemon(true);
th.start();

call() メソッドに時間のかかる処理を記述します。バックグラウンドスレッドロジックです。

call() メソッドが呼ばれたら初期値をセットします。

updateMessage() メソッド、updateValue() メソッド、updateProgress() メソッドはプロパティバインドを利用します。

バックグラウンドスレッドが開始されたらキャンセル操作がリクエストされたかも監視しなければいけません。

キャンセルは java.​util.​concurrent.​FutureTask クラスの isCancelled() メソッドを使います。

今回、スレッドをスリープさせているので InterruptedException をスローする場合があります。

また InterruptedException は Task のキャンセルの結果として発生する場合があるため、確実に InterruptedException を処理し、キャンセル状態を調べる必要があります。

それに対応するために 102 行目の catch 節のところにも isCancelled() メソッドを使用しています。

このようにバックグラウンドスレッドロジック内にブロッキング・コールがある場合は注意が必要となります。

バックグラウンドスレッドでの処理の結果の一部を返すために 110 行目に updateValue() メソッドを使います。

同様に 109 行目で messageLabel 、111 行目で progressBar の更新も行っています。

これらの更新は JavaFX のバインドという便利な機能を使います。

Task クラスのプロパティと Label のテキストプロパティ、ProgressBar の プログレスプロパティとバインドします。

168 行目から次のようにバインドしています。

// textProperty と Workerオブジェクトの stateProperty をバインド
statusLabel.textProperty().bind(task.stateProperty().asString());
// textProperty と Workerオブジェクトの messageProperty をバインド
messageLabel.textProperty().bind(task.messageProperty());
// textProperty と Workerオブジェクトの valueProperty をバインド
interimResult.textProperty().bind(task.valueProperty().asString());
// progressProperty と Workerオブジェクトの progressProperty をバインド
progressBar.progressProperty().bind(task.progressProperty());

これで自動的に Task クラス(Workerオブジェクト)のプロパティ updateXXX() メソッドで更新されたら Label 、ProgressBar も更新されます。

もし、キャンセル操作が実行され、プログラムの実行結果の一部が表示されたままになるのが嫌なら

141 行目の Worker オブジェクトの状態が変化したときのコールバックメソッドである cancelled() メソッドの処理でいったん unbind() メソッドによりバインドを解除して初期値を設定し直すといいでしょう。

@Override
protected void cancelled() {
    super.cancelled();
    updateMessage(“Cancelled!”);
    System.out.println(“Call cancelled()”);
    progressBar.progressProperty().unbind();
    progressBar.setProgress(0.0);
    interimResult.textProperty().unbind();
    interimResult.setText(“INTERIM RESULT”);
}

このようなコールバックメソッドはこの他にもあり、全部で5種類あります。

必要に応じて便利に使えます。

118 行目から 158 行目を参照ください。

バックグラウンドタスクが無事に終了したら 134 行目の succeeded() メソッドがコールバックされます。

@Override
protected void succeeded() {
    super.succeeded();
    updateMessage(“Succeeded!”);
    System.out.println(“Call succeeded()”);
    resultLabel.setText(“RESULT: ” + getValue().toString());
}

ここで Task クラスに戻り値がある場合それを取得します。

戻り値の型はジェネリクスの型パラーメターで指定されたものです。

今回のプログラムでは Long となっています。

必然的に Call() メソッドの戻り値も Long です。

計算結果は 138 行目で javafx.​concurrent.​Task クラスの getValue() メソッドで取得しています。

                resultLabel.setText(“RESULT: ” + getValue().toString());

そして、計算結果を Label のテキストとしてセットしています。

これらのコールバックメソッドは JavaFX アプリケションスレッド上で実行されるので RuntimeException も出ません。

コールバックメソッドを利用する以外にも WorkerStateEvent を使ってイベント処理として扱うこともできます。

160 行目から 165 行目のようにイベントハンドラを登録して使用します。

// WorkerStateEven を使ってWorkerオブジェクトの状態を監視
task.setOnScheduled(wse -> System.out.println(“setOnScheduled”));
task.setOnRunning(wse -> System.out.println(“setOnRunning”));
task.setOnSucceeded(wse -> System.out.println(“setOnSucceeded”));
task.setOnCancelled(wse -> System.out.println(“setOnCancelled”));
task.setOnFailed(wse -> System.out.println(“setOnFailed”));

では、このプログラムを動かしたときの Worker オブジェクトの state プロパティ がどのように変化するか確認します。

プログラムが完する場合次のように出力されます。

setOnScheduled
Call scheduled()
setOnRunning
Call running()
setOnSucceeded
Call succeeded()

この出力結果から

SCHEDULED
RUNNING
SUCCEEDED

と遷移しているのが解ります。

プログラムを途中でキャンセルしてみる場合も確認します。

setOnScheduled
Call scheduled()
setOnRunning
Call running()
setOnCancelled
Call cancelled()
Canceled by InterruptedException.

予想通りの結果ですね。

SCHEDULED
RUNNING
CANCELLED

上記のように遷移しています。これらの動作は想像通りでした。

コールバックメソッドより WorkerStateEvent を使ってイベントハンドラを登録したほうが早い結果となっています。

だからといってメリット、デメリットがあるかどうかは私には解りません。

さて、最後に、「START」ボタン、「CANCEL」ボタンの活性化、非活性化をみてみましょう。

175 行目から 177 行目です。

// disableProperty と Workerオブジェクトの stateProperty をバインド
startButton.disableProperty().bind(task.stateProperty().isEqualTo(RUNNING));
cancelButton.disableProperty().bind(task.stateProperty().isNotEqualTo(RUNNING));

Button の disableProperty と Workerオブジェクトの stateProperty をバインドしているだけです。

startButton は Workerオブジェクトの stateProperty が RUNNING なら非活性化となります。

cancelButton は Workerオブジェクトの stateProperty が RUNNING でなければ非活性化となります。

つまり、Workerオブジェクトの stateProperty が RUNNING の場合だけ活性化します。

これでいちいち操作を行うたびに Button を活性化、非活性化処理を記述しなくてすみます。

このように JavaFX には非同期処理を簡単に扱うことができるようになっています。

SwingWorker を使って非同期処理プログラムを組んでいるのなら JavaFX の javafx.concurrentパッケージを使ってみて時代の流れを感じ取ってみてはいかがでしょうか。

お終い!

I wish you a Merry Christmas.


«

Comment

Trackback

  1. […] 実は、最初は Task, Service まわりの非同期処理の話を書こうと思っていました。 ただ、二日前に急遽枠を取ったものの、よく見ると 6日目の内容 とダダ被りしていることに気付きました。 […]

Leave a Reply

* が付いている項目は、必須項目です!

次の HTML タグと属性を利用できます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

*

Trackback URL