Thread.sleep時にInterruptedExceptionが発生してしまう。

Question

前提

とあるWebシステムの保守作業、あるデータ登録機能でデッドロックが発生しまして、その対処を行っています。
私が参画前の1年ほど前のリリース以降に発言した障害で、本来であればデッドロックの根本原因を突き止めてから対処したいところですが、
如何せん十数年運用されているそれなりの規模のシステムで、最近参画した私が意見したところで一蹴されるのみでした。
つまりはかなーり上の方から、対症療法でさっさと直せっていうお達しですので、「そもそもデッドロックは～」という話は今回はなしでお願いします。。。

実現したいこと

・Thread.sleep使うの初めて。。。
・所定条件を満たした際、Thread.sleep(n * 1000)で待機処理をしたい。
実装したThread.sleep(n * 1000)まで到達し、実行されていることは確認済み

バージョン

Java6

発生している問題・エラーメッセージ

java.lang.InterruptedException: sleep interrupted

該当のソースコード

■元々のソース

public List<String> executeSQL(param) {
  return executeSql;
}

■修正後

public List<String> executeSQL(param) {
  return deadlockRetry(param);
}

// デッドロック対処メソッド
private deadlockRetry(param) {
  for (int retryCnt = 0; retryCnt <= maxCnt; retryCnt++) {
    try {
      // SQL実行
    } catch (SQLException e) {
      int errCode = e.getErrorCode();
      if (errCode == 1205) {
        Thread.sleep(10000);
        continue;
      } else {
        throw e:
      }
    }
    break;
  }
}

試したこと、状況

・元々の作りの問題で、デッドロックの発生箇所はログから判明しているが、突合した相手のプロセスは判明していないため、強制的にデッドロックを発生させており、再現環境ではない。
→ Eclipseの表示ビューから強制的にnew SQLExceptionをスローしているがその影響はあるか？

・私自身がThreadについてあまり知見が深くない。
・調べたところ、他スレッドからの干渉があった場合に当該エラーが発生することは認識。
→ それ以上の調査結果が得られなかった・・・

・Thread.sleepの実行位置は最初に動くmainスレッドからすると４スレッド目
（main → logic → dao:SQL実行 → dao:デッドロック対処メソッド）
・デバッグで確認するも呼び出し元の上位３スレッド以外のスレッドは存在しない。

聞きたいこと

Thread.sleepが正しく発動する条件。
→ そもそもmainスレッドレベルでsleepをかけないと、呼び出し元スレッドが干渉してくることがあるのか？
→ それとも実装方法に問題あり？

Thread.sleep以外にもっとベターな待機処理があるかどうか。

不備不足あれば追記いたしますので、ご指摘いただけると幸甚です。

Comments

[moredeep]

ただの勘ですけど、daoが悪さしているんじゃないかなと。
Sleepしている間にDAOは何をしているんですかね？DAOがタイムアウト等で破棄されてなし崩し的にThreadを閉じることになってたりしませんか？

[rnosh]

厳密にいうと、デッドロックの対処メソッドもdao内におります。
対象箇所が複数あるため、元のSQL実行メソッドは残しつつ、logicから受け取ったパラメータをそのままデッドロックの対処メソッドに渡すといった形です。
さらに言えば、元々のdaoのSQL実行メソッドは1stepのみなので、デッドロックの対処メソッドの返却値をリターンするだけのものになっています。
投稿の記載はそのように修正いたしました...

[moredeep]

mainスレッドからすると４スレッド目とありますが、こちらも間違いでしょうか・・・？
スレッドを呼び出し階層と混同して数えてしまっていたりしませんか？？

どちらにせよ、Sleepしているスレッドを起動したスレッドが悪さしているという考えは継続中です。(logicですかね？)DBアクセスのタイムアウトでスレッド破棄されるというバグを最近見たので。。。

[rnosh]

スレッドのカウントは、Eclipseデバッグ時のデバッグビューで確認した形です。
実行すると、mainスレッド・logicスレッド・dao:元のSQL実行スレッド・dao:デッドロック対処メソッドの４つになっていたので、呼び出し順的に４スレッド目と判断したのですが、、、誤りでしょうか・・・？

Answer 1

Thread.sleepが正しく発動する条件。

まずInterruptedExceptionが発生する理由について正確にわかってはないですが、こちら(javaのバージョンによる違いがあるかもしれないですが、、、)にあるようにSQLのトランザクションを中止する割り込みをした後にスレッドを待ち状態にしたために起きたと思います。
逆に言えば、正しく発動する条件はThread.sleepの前かその実行中において割り込み処理をしないことになるかと思います。

Thread.sleep以外にもっとベターな待機処理があるかどうか。

すみませんがわからないです。とりあえずworkaroundだけ紹介しますが、あまり良いやり方ではないと思います。
Thread.sleep(***)の直前にThread.interrupted()を実行してください。そうすると割り込みステータスをクリアすることが出来ます。
ただ、このメソッドの本来の役割は割り込みがあったかを伝えるものであって、割り込みステータスをキャンセルさせたいものではないと思っています。ので、あまり良いやり方ではないと思っています。

以下試しに作った実装になります。

import java.util.*;

public class Main {
    public static void main(String[] args) throws Exception {
        
        final boolean[] wait = new boolean[]{true};
        
        // ---- InterruptedException が呼ばれるパターン ----
        System.out.print("Start pattern 1.\n");

        Thread th1 = new Thread(new Runnable() {
            @Override
            public void run() {
                
                // 適当に待つ
                while(wait[0]) {
                    for(int i=0; i<1000; i++) {
                        int a = 1+1;
                    }
                };
                
                try {
                    Thread.sleep(1000);
                    System.out.print("I have slept very well.\n");
                } catch(InterruptedException e) {
                    System.out.print("InterruptedException thrown.\n"); // <- こっちが呼ばれる
                }
            };
        });
        
        th1.start();
        
        // 適当に待つ
        for(int i=0; i<5000; i++) {
            int a = 1+1;
        }

        th1.interrupt();  // <- 割り込み発生
        wait[0] = false;
        
        th1.join();
        
        // ---- InterruptedException が呼ばれないパターン ----
        System.out.print("Start pattern 2.\n");

        wait[0] = true;
        Thread th2 = new Thread(new Runnable() {
            @Override
            public void run() {
                
                // 適当に待つ
                while(wait[0]) {
                    for(int i=0; i<1000; i++) {
                        int a = 1+1;
                    }
                };
                
                // 割り込みステータスをクリアする
                Thread.interrupted();
                
                try {
                    Thread.sleep(1000);
                    System.out.print("I have slept very well.\n"); // <- 割り込みステータスをクリアしたのでこっちが呼ばれる
                } catch(InterruptedException e) {
                    System.out.print("InterruptedException thrown.\n"); 
                }
            };
        });
        
        th2.start();
        
        // 適当に待つ
        for(int i=0; i<5000; i++) {
            int a = 1+1;
        }

        th2.interrupt();  // <- 割り込み発生
        wait[0] = false;
        
        th2.join();
    }
}

/* Results
==================================
Start pattern 1.
InterruptedException thrown.
Start pattern 2.
I have slept very well.
==================================
*/

Comments

[rnosh]

ご回答ありがとうございます。

> SQLのトランザクションを中止する割り込みをした後にスレッドを待ち状態にしたために起きたと思います。
このアドバイスを受けまして、Eclipse表示ビューからの強制SQLExceptionではなく、SQLを書き換えて処理の流れの中で正しくSQLExceptionを発生させ、取得変数をいじるだけで突入させたところ、InterruptedExceptionが発生することなく、スレッドが待機しました。

Eclipse表示ビューの強制実行は別スレッド判定(？)になることを学びました・・・

ありがとうございました！

Answer 2

Thread.sleepがうまく動かない

とは、どうのような現象のことを指していますか？
なぜ、うまく動いていないと判断していますか？

所定条件を満たした際、Thread.sleep(n * 1000)で待機処理をしたい。

Thread.sleepが正しく発動する条件。

とくに条件はなく、Thread.sleep(10000);に到達すれば、sleepすると思いますが。
条件とは、SQLExceptionが発生して、Errcodeが1205だったらという意味ですか？

デッドロックのエラーコードは1205で合っていますか？(SQLServer？)

Thread.sleep以外にもっとベターな待機処理があるかどうか。

待機処理は、sleepでよいかと思います。

---

まずは、うまく動かないこと？を正しく検証してみては、どうでしょうか。
当該スレッドは、sleepのロジックを通っていますか？

Comments

[rnosh]

回答ありがとうございます。
少々言葉足らずでしたでしょうか、申し訳ございません。

デバッグで検証したうえで動かないので質問をした次第です。
Thread.sleepまで到達したうえで、InterruptedExceptionが発生しており、その解決法がわからなかったので。
(そもそも記載したInterruptedExceptionがThread.sleep未到達で発生するのかわかりませんが・・・)
エラーコードについてはSQL Serverですので1205で間違いないと思いますが、冒頭にも記載いたしました通り、そこに関しては不問です。

故に、確実に到達したことを確認した上での質問だということを記載するよう修正いたしますね。