Thread.stop、Thread.suspend、 Thread.resume、および Runtime.runFinalizersOnExit が推奨されない理由

Thread.stop が推奨されないのはなぜですか

本質的に安全ではないからです。スレッドを停止すると、そのスレッドがロックしたすべてのモニターのロックが解除されます。(ThreadDeath 例外がスタックまで伝わると、モニターのロックが解除される。)これらのモニターによって以前保護されていたオブジェクトが整合性のない状態になると、ほかのスレッドも、これらのオブジェクトが整合性のない状態にあると見なします。そのようなオブジェクトは、「壊れた」オブジェクトと呼ばれます。壊れたオブジェクトに対してスレッドが操作を実行すると、予期しない結果になる可能性があります。この動作は、微妙で検出が困難な場合と、はっきりと通知される場合があります。チェックされないほかの例外とは異なり、ThreadDeath は、スレッドをそのまま強制的に終了します。このため、ユーザは、プログラムが壊れる可能性を警告されることがありません。プログラムが壊れていることは、実際に損傷を受けたしばらくあとに明らかになり、それが数時間後または数日後になることもあります。

ThreadDeath 例外をキャッチし、壊れたオブジェクトを修復することはできないのですか

理論的には、おそらく可能です。ただし、正しいマルチスレッドコードを記述するのは「非常に」複雑な作業です。これがほとんど実行不可能な作業であることは、次の 2 つの理由によります。

1. スレッドは、ThreadDeath 例外を「ほとんどすべての場所で」スローする。このことを念頭に置いて、すべての同期化されたメソッドおよびブロックを詳細に調査する必要がある
2. スレッドは、1 番目の例外のクリーンアップ中 (catch または finally 節) に、2 番目の ThreadDeath をスローすることがある。クリーンアップは、正常に終了するまで繰り返し実行される必要がある。この動作を確実に行うコードは非常に複雑になる

Thread.stop(Throwable) についてはどうですか

上で説明した問題すべてに加えて、このメソッドは、対象とするスレッドの処理準備ができていないという例外 (このメソッドがなかったならスレッドがスローできないはずの、チェックされる例外を含む) を発生させるのに使用されることがあります。たとえば、次のメソッドの動作は、Java の throw 操作と同じですが、呼び出し側のメソッドがスローする可能性のあるチェックされる例外すべてが宣言されていることを保証しようとするコンパイラをだまして失敗させます。

    static void sneakyThrow(Throwable t) {
        Thread.currentThread().stop(t);
    }

Thread.stop の代わりに何を使うべきですか

stop の代わりとしては、多くの場合、ターゲットスレッドの実行を停止するべきことを示す何らかの変数を単に変更するコードを使用します。ターゲットスレッドは、この変数を定期的に検査し、実行を停止するべきことを変数が示している場合には、スレッドの run メソッドから通常の方法で復帰する必要があります。これは、Java ソフトウェアのチュートリアルで常に推奨している方法です。停止要求の即時通信を確実にするには、変数を volatile にする (または、変数へのアクセスを同期化する) 必要があります。

たとえば、アプレットに次の start、stop、および run メソッドが含まれているとします。

    private Thread blinker;

    public void start() {
        blinker = new Thread(this);
        blinker.start();
    }

    public void stop() {
        blinker.stop();  // UNSAFE!
    }

    public void run() {
        Thread thisThread = Thread.currentThread();
        while (true) {
            try {
                thisThread.sleep(interval);
            } catch (InterruptedException e){
            }
            repaint();
        }
    }

    private volatile Thread blinker;

    public void stop() {
        blinker = null;
    }

    public void run() {
        Thread thisThread = Thread.currentThread();
        while (blinker == thisThread) {
            try {
                thisThread.sleep(interval);
            } catch (InterruptedException e){
            }
            repaint();
        }
    }

長い間 (入力などを) 待機しているスレッドをどうすれば停止できますか

その目的には、Thread.interrupt を使用します。上と同じ「状態に応じた」シグナル機構を使用できますが、状態変更 (前の例では blinker = null) のあとに、Thread.interrupt を呼び出して待機状態に割り込むことができます。

    public void stop() {
        Thread moribund = waiter;
        waiter = null;
        moribund.interrupt();
    }

    Thread.currentThread().interrupt();

スレッドが Thread.interrupt に応答しないとどうなりますか

アプリケーション独自の技法が使用可能な場合もあります。たとえば、スレッドが既知のソケット上で待機している場合は、ソケットを閉じることによりスレッドをただちに復帰させることができます。しかし、残念ながら、汎用的に使用できる技法はありません。待機しているスレッドが Thread.interrupt に応答しないすべての状況では、そのスレッドは Thread.stop にも応答しないことに注意してください。そのような状況としては、意図的なサービス妨害攻撃や、thread.stop と thread.interrupt が適切に機能しない入出力操作などがあります。

Thread.suspend および Thread.resume が推奨されないのはなぜですか

Thread.suspend は、本質的にデッドロックを起こす傾向があります。ターゲットスレッドが、中断される時点で、重要なシステムリソースを保護するモニターをロックしている場合、ターゲットスレッドが再開されるまでどのスレッドもそのリソースにアクセスできません。このとき、ターゲットスレッドを再開するスレッドが、resume を呼び出す前にこのモニターをロックしようとすると、デッドロックが発生します。通常、このようなデッドロックは、プロセスの「凍結」により明らかになります。

Thread.suspend と Thread.resume の代わりに何を使うべきですか

Thread.stop の場合と同様、賢明なアプローチは、スレッドの望ましい状態 (実行中または中断中) を示す変数を「ターゲットスレッド」にポーリングさせることです。望ましい状態が中断中である場合、スレッドは Object.wait を使用して待機します。スレッドが再開されたときは、ターゲットスレッドは Object.notify を使って通知を受けます。

たとえば、アプレットに次のような mousePressed イベントハンドラが含まれており、それが blinker というスレッドの状態を切り替えるとします。

    private boolean threadSuspended;

    Public void mousePressed(MouseEvent e) {
        e.consume();

        if (threadSuspended)
            blinker.resume();
        else
            blinker.suspend();  // DEADLOCK-PRONE!

        threadSuspended = !threadSuspended;
    }

    public synchronized void mousePressed(MouseEvent e) {
        e.consume();

        threadSuspended = !threadSuspended;

        if (!threadSuspended)
            notify();
    }

                synchronized(this) {
                    while (threadSuspended)
                        wait();
                }

    public void run() {
        while (true) {
            try {
                Thread.currentThread().sleep(interval);

                synchronized(this) {
                    while (threadSuspended)
                        wait();
                }
            } catch (InterruptedException e){
            }
            repaint();
        }
    }

Java において同期化に要するコストは、プラットフォームが成熟するにつれて減少していますが、まったくなくなることはありません。簡単な技法を使用して、上の「実行ループ」の反復処理に追加した同期処理を省くことができます。追加された同期ブロックは、スレッドが実際に中断されている場合にのみ同期ブロックを入力する、わずかに複雑なコードに置き換えられます。

                if (threadSuspended) {
                    synchronized(this) {
                        while (threadSuspended)
                            wait();
                    }
                }

明示的な同期化を行わない場合は、threadSuspended を volatile に設定して、一時停止要求の通信が速やかに行われるようにしてください。

    private boolean volatile threadSuspended;

    public void run() {
        while (true) {
            try {
                Thread.currentThread().sleep(interval);

                if (threadSuspended) {
                    synchronized(this) {
                        while (threadSuspended)
                            wait();
                    }
                }
            } catch (InterruptedException e){
            }
            repaint();
        }
    }

今までの 2 つの手法を組み合わせれば、安全に「停止」または「中断」させることのできるスレッドを生成できますか

この状況を正すには、stop メソッドで、ターゲットスレッドが中断されている場合に、そのスレッドをただちに再開する処理を確実に実行しなければなりません。ターゲットスレッドは、再開したのち、自身が停止されたことをただちに認識して、適切な方法で終了しなければなりません。そのような処理を加えた run および stop メソッドは、次のようになります。

    public void run() {
        Thread thisThread = Thread.currentThread();
        while (blinker == thisThread) {
            try {
                thisThread.sleep(interval);

                synchronized(this) {
                    while (threadSuspended && blinker==thisThread)
                        wait();
                }
            } catch (InterruptedException e){
            }
            repaint();
        }
    }

    public synchronized void stop() {
        blinker = null;
        notify();
    }

Thread.destroy についてはどうですか

Runtime.runFinalizersOnExit が推奨されないのはなぜですか

さらに、その呼び出しは、VM グローバルフラグを設定するという意味で、「スレッドに対して安全」ではありません。これは、ファイナライザを持つあらゆるクラスを、ライブオブジェクトのファイナライズに対して防御するようにコーディングしなければならないことにつながります。

Copyright © 1995-99 Sun Microsystems, Inc.All Rights Reserved. 機能の提案またはコメントの送り先

Java ソフトウェア