Javaにおけるマルチスレッドプログラミングは、システムのパフォーマンスを向上させるための強力な手段ですが、同時に開発者を悩ませる複雑な例外処理を伴います。

その中でも、特に多くの開発者が「とりあえず空のcatchブロックで握り潰してしまう」という誤った対処をしてしまいがちなのが java.lang.InterruptedException です。

この例外は単なるエラー通知ではなく、スレッド間の通信や協調的なキャンセル処理を実現するための重要なメカニズムの一部です。

正しく理解し対処しなければ、アプリケーションのシャットダウンが正常に行われなかったり、スレッドが意図せず動き続けたりといった、デバッグの困難な不具合を引き起こす原因となります。

本記事では、InterruptedExceptionの発生原因から、実務で使えるベストプラクティス、さらにはスレッドの状態管理の仕組みまで、プロフェッショナルが知っておくべき知識を徹底的に解説します。

目次 [ close ]
  1. InterruptedExceptionとは何か
    1. 割り込みの仕組みとスレッドフラグ
  2. InterruptedExceptionが発生する主な原因
  3. やってはいけないNGパターン：例外の握り潰し
  4. InterruptedExceptionの正しい対処法
    1. 1. 例外をそのままスロー（伝播）させる
    2. 2. 割り込みステータスを復元する
  5. 実践的なコード例：スレッドの安全な停止
  6. 割り込みに関するメソッドの違い
  7. 高度なマルチスレッド環境での注意点
    1. ExecutorServiceとInterruptedException
    2. I/O操作と割り込み
  8. まとめ

InterruptedExceptionとは何か

java.lang.InterruptedException は、Javaのチェック例外 (Checked Exception) の一種であり、「実行中のスレッドに対して、中断（割り込み）の要求があったこと」を知らせるための例外です。

Javaのスレッドモデルにおいて、あるスレッドを外部から強制終了させるためのメソッド（例えば Thread.stop() など）は、安全性やデータ整合性の観点から現在は非推奨となっています。

その代わりに採用されているのが、「割り込み（Interruption）」という協調的なメカニズムです。

あるスレッドが「待機状態（Waiting）」や「スリープ状態（Timed Waiting）」にあるときに、別のスレッドから Thread.interrupt() メソッドが呼び出されると、待機中のメソッドは InterruptedException をスローして即座に処理を中断します。

これにより、スレッドは「自分が中断を求められている」ことを検知し、安全に処理を終了させる機会を得ることができるのです。

割り込みの仕組みとスレッドフラグ

Javaの各スレッドは、内部的に 「割り込みステータス（interrupted status）」 と呼ばれるブール値のフラグを持っています。

デフォルトは false ですが、誰かがそのスレッドに対して interrupt() を実行すると、このフラグが true に変わります。

ここで重要なのは、InterruptedExceptionがスローされると、この割り込みステータスは自動的にクリア（falseにリセット）されるという点です。

この仕様こそが、多くの開発者が例外処理でミスを犯す原因となっています。

InterruptedExceptionが発生する主な原因

この例外は、スレッドが「何らかの待ち状態」にあるときに発生します。

具体的にどのような状況で発生するのか、代表的なメソッドを以下の表にまとめました。

メソッド名発生するシチュエーション
Thread.sleep(long)指定した時間だけスレッドを一時停止している間。
Object.wait()他のスレッドからの通知（notify）を待っている間。
Thread.join()他のスレッドの終了を待っている間。
BlockingQueue.put() / take()キューが満杯、または空で、操作が可能になるのを待っている間。
java.util.concurrent.locks.Lock.lockInterruptibly()ロックの取得を待機している間。

これらのメソッドはすべて、呼び出し側に対して「この処理は時間がかかる可能性があり、かつ途中で中断される可能性がある」ことをコンパイル時に明示（throws）しています。

やってはいけないNGパターン：例外の握り潰し

最も避けるべきなのは、以下のような実装です。

Javaの初心者だけでなく、中堅エンジニアでもついつい書いてしまうことがありますが、これはアンチパターンの典型です。

Java
// 絶対にやってはいけない例
try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    // 何もしない（握り潰し）
}

なぜこれが危険なのでしょうか。

その理由は、前述した「割り込みステータスのクリア」にあります。

スレッドプール（ExecutorService）などを使用している場合、フレームワークはスレッドを再利用したり、シャットダウン時に各スレッドに割り込みを送ったりします。

もしあなたが例外をキャッチして何もしなければ、上位の呼び出し元（ライブラリやフレームワーク）は、スレッドに中断要求が出されたという事実を知ることができなくなります。

その結果、プログラムが終了しない、あるいはキャンセルしたはずのタスクが実行され続けるといった問題が発生します。

また、単にログを出力するだけで終わらせるのも不十分です。

Java
// これも不十分な例
try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    e.printStackTrace(); // ログは出るが、割り込みフラグはクリアされたまま
}

InterruptedExceptionの正しい対処法

プロフェッショナルなJava開発において、InterruptedException への対処法は大きく分けて2つあります。

状況に応じてどちらかを選択する必要があります。

1. 例外をそのままスロー（伝播）させる

自作のメソッド内でこの例外が発生した場合、最もシンプルで誠実な対応は、メソッドのシグネチャに throws 句を追加して、呼び出し元に判断を委ねることです。

Java
public void doWork() throws InterruptedException {
    // 処理の途中でsleepやwaitを行う
    Thread.sleep(5000);
    System.out.println("Work completed");
}

この方法のメリットは、呼び出し元が「このメソッドは中断される可能性がある」と認識でき、呼び出し元自身のキャンセル戦略に合わせられる点にあります。

ライブラリや共有コンポーネントを作成する場合は、この設計が推奨されます。

2. 割り込みステータスを復元する

もし、メソッドのシグネチャを変更できない場合（例えば Runnable インターフェースを実装している場合など）は、キャッチした後に自分で割り込みフラグを立て直す必要があります。

Java
public void run() {
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        // 1. ログを出力（必要に応じて）
        System.err.println("Thread was interrupted");
        
        // 2. 割り込みステータスを復元する
        Thread.currentThread().interrupt();
        
        // 3. 速やかにクリーンアップして終了する
        return;
    }
}

Thread.currentThread().interrupt() を呼び出すことで、一度クリアされてしまった割り込みフラグを再び true に戻します。

これにより、コールスタックのさらに上位にあるコードが「あ、このスレッドは中断を求められているんだな」と判断できるようになります。

実践的なコード例：スレッドの安全な停止

次に、実務でよく遭遇する「ループ処理を行うスレッド」を安全に停止させる実装例を見てみましょう。

Java
public class WorkerTask implements Runnable {
    @Override
    public void run() {
        try {
            // スレッドが割り込まれていないか、ループの条件でもチェックするのが望ましい
            while (!Thread.currentThread().isInterrupted()) {
                // 重い処理のシミュレーション
                performComplexCalculation();
                
                // ブロッキングメソッドの呼び出し
                Thread.sleep(500); 
            }
        } catch (InterruptedException e) {
            // sleep中に割り込みが発生した場合はここに来る
            // この時点で割り込みフラグはクリアされている
            System.out.println("Worker interrupted during sleep. Cleaning up...");
        } finally {
            // 共通のクリーンアップ処理（ファイルクローズ、DB接続解除など）
            cleanup();
            
            // 必要に応じてフラグを復元
            Thread.currentThread().interrupt();
            System.out.println("Worker thread finished safely.");
        }
    }

    private void performComplexCalculation() {
        // 計算処理...
    }

    private void cleanup() {
        // リソース解放処理...
    }
}

このコードでは、ループの条件式で isInterrupted() をチェックしつつ、sleep 中の割り込みに対しても catch ブロックで適切に対応しています。

割り込みに関するメソッドの違い

Javaの Thread クラスには、割り込み状態を確認・操作するための似たような名前のメソッドが3つあります。

これらを混同するとバグの原因になるため、整理しておきましょう。

interrupt()

対象のスレッドに対して割り込みをリクエストします（フラグをtrue にする）。

isInterrupted()

インスタンスメソッドです。

そのスレッドの割り込みステータスを返しますが、フラグの状態は変更しません。

Thread.interrupted()

静的メソッドです。

現在実行中のスレッドの割り込みステータスを返しますが、呼び出し後にフラグをクリア (falseにリセット) します。

以下に、それぞれの違いを比較表にまとめました。

メソッド種類役割フラグへの影響
interrupt()インスタンス割り込み要求を送るtrueにする
isInterrupted()インスタンス現在の状態を確認する変化なし
Thread.interrupted()静的状態を確認してリセットするfalseにする

特に Thread.interrupted() は、一度呼び出すとフラグが消えてしまうため、その結果を無視すると割り込み情報が失われる点に注意してください。

高度なマルチスレッド環境での注意点

現代のJava開発では、生の Thread クラスを直接操作するよりも、ExecutorService や CompletableFuture を利用することが一般的です。

これらのAPIを使用する場合の割り込み処理についても触れておきます。

ExecutorServiceとInterruptedException

ExecutorService.shutdownNow() を呼び出すと、実行中のすべてのタスクに対して interrupt() が送られます。

このとき、タスク内のコードが InterruptedException を正しく処理していれば、プール内のスレッドは速やかに終了し、アプリケーション全体が安全に停止できます。

もしタスクが例外を握り潰していると、shutdownNow() を呼んでもスレッドが死なず、JVMが終了しないという事態に陥ります。

I/O操作と割り込み

実は、すべてのブロッキング操作が InterruptedException を投げるわけではありません。

例えば、従来の java.io パッケージ（InputStreamのreadなど）によるソケット通信は、interrupt() を受けても例外をスローせず、ブロックし続けます。

これに対処するには、NIO (java.nio) のチャネルを使用するか、ソケットをクローズすることで強制的に例外（SocketException）を発生させるなどの手法が必要です。

自分が使用しているメソッドが「割り込み可能（Interruptible）」かどうかをJavaDocで確認する癖をつけましょう。

まとめ

java.lang.InterruptedException は、Javaにおける協調的マルチスレッド処理の根幹をなす重要な例外です。

これを単なるエラーとして無視することは、プログラムの制御権を放棄することと同義です。

本記事で解説した重要なポイントを振り返ります。

  • 割り込みは強制終了ではなく「要求」である： スレッドが自ら中断に協力する必要がある。
  • 例外がスローされるとフラグはクリアされる： そのため、単にキャッチするだけでは中断要求があった事実が消えてしまう。
  • ベストプラクティスは2つ： 呼び出し元へ throws するか、Thread.currentThread().interrupt() でフラグを復元する。
  • 握り潰しは厳禁： リソース漏洩やシャットダウン不能の原因となる。

正しい例外処理を実装することは、堅牢でメンテナンス性の高いシステムを構築するための第一歩です。

次に InterruptedException に遭遇したときは、この記事を思い出し、適切に割り込みステータスを管理してみてください。