ScheduledThreadPoolの中で文字列フォーマットのエラーがスローされず処理がブロックされてしまう

Question

print formatで、このように正しくないフォーマットを書いて実行すると、UnknownFormatConversionExceptionがスローされます。

System.out.printf("%.f%n", 1.23f);
// => Exception in thread "main" java.util.UnknownFormatConversionException: Conversion = '.'

Concurrency Utilities APIのスレッドプールを使った場合、スケジュールでないスレッドプールで以下のようにしても、同様に例外がスローされます。
スレッドのところが、"pool-1-thread-1"になりますが、mainスレッドのときと同じエラーになります。

Executors.newFixedThreadPool(1).execute(() -> {
    System.out.println("thread: " + Thread.currentThread());
    System.out.printf("%.f%n", 1.23f);
});

Executors.newCachedThreadPool().execute(() -> {
    System.out.println("thread: " + Thread.currentThread());
    System.out.printf("%.f%n", 1.23f);
});

ところが、Executors.newScheduledThreadPool(1)で同じことをしようとすると、処理がブロックされてしまいます。
executeメソッドでなくて、scheduleAtXXXメソッドでも同様です。

Executors.newScheduledThreadPool(1).execute(() -> {
    System.out.println("thread: " + Thread.currentThread());
    System.out.printf("%.f%n", 1.23f);
});

"pool-1-thread-1"のスタックトレースを見てみると、LockSupportのparkでブロックされているようです。

sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

これって、バグでしょうか？
実行環境は、Java 8 u66で、Mac 10.11.2 と Windows 7 professional 64bit のどちらでも再現しました。

よろしくお願いします。

Answer 1

処理がブロックされてしまいます。

と判断されたのは、例外スタックトレースが出力されていない、ということからかな、と想像します。

---

スタックトレースが出力されないのは…そのまんまですが、内部で出力する処理を行っていないためですね。
printlnのところにブレークポイントを設定してコールスタックをたどるとわかりますが、ScheduledFutureTaskクラス(の親クラスのFutureTask)内でThrowableをキャッチして処理しているようです。
自前で用意したFutureTaskインスタンスからなら例外を取り出せますが、ここで後から取り出すのは…できないんじゃないでしょうか。

一方で、newFixedThreadPoolの方は、新しくスレッドを生成して普通にRunnableを実行しているだけなので、例外が出るとデフォルトのUncaughtExceptionHandlerが呼ばれているのでしょう。
(自分でスレッドを生成して実行した時と同様、スタックトレースが出力される)

---

後続のRunnableを設定してみて、それが正しく実行されていることで、処理がブロックされているわけではないというのは確認できるのではないでしょうか(スレッドを1つしか作っていない場合)。

public static void main(String[] args) {

    ExecutorService ses = Executors.newScheduledThreadPool(1);

    ses.execute(() -> {
        try {
            System.out.println("thread: " + Thread.currentThread());
            System.out.printf("%.f%n", 1.23f);
        } catch (RuntimeException e) {
            e.printStackTrace();
            throw e;
        }
    });

    ses.execute(() -> {
        System.out.println("post process");
    });

    ses.shutdown();
}

Comments

[argius]

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

ブロックされていると判断したのは、質問欄の最後の方に記載しているスタックトレースにより判断しました。これは、スレッドダンプを出すかそれに類似した方法で取得しています。
ただこれは、例外が出た後で処理が待機しているだけということですね。ここが勘違いでした。
デバッグで追っかけるのも忘れていました。

ご呈示いただいたコードでprintStackTraceが出るのと次のタスクが同じスレッドで実行されたのを確認しました。

もうひとつは、setDefaultUncaughtExceptionHandlerでUncaughtExceptionHandlerを設定していても、ScheduledFutureTaskの例外は処理されないということですよね？
これがおそらく根本的な認識誤りだったんだと思います。

以上、ご認識あってますでしょうか？

[eripong]

yukihaneさん

> 自前で用意したFutureTaskインスタンスからなら例外を取り出せますが、ここで後から取り出すのは…できないんじゃないでしょうか

一応、
ScheduledExecutorService ses = Executors.newScheduledThreadPool(1);
にして、
Future future = ses.schedule(() -> {
-(略)-
}, 0, NANOSECONDS);
すると、
future.get();
した際に以下のような例外が発生して内容の確認はできる様です。

java.util.concurrent.ExecutionException: java.util.UnknownFormatConversionException: Conversion = '.'
-(略)-
Caused by: java.util.UnknownFormatConversionException: Conversion = '.'
-(略)-

[退会済みユーザー]

- argius さん
FutureTaskの中で↓みたいにThrowableをキャッチして処理している(そして再スローはしていない)ので、そもそもUncaughtなExceptionは無い、というのが正確な表現ですかね。
try {
result = c.call();
ran = true;
} catch (Throwable ex) {
result = null;
ran = false;
setException(ex);
}

> 質問欄の最後の方に記載しているスタックトレースにより判断しました
これはおそらく、単純にプールされたワーカースレッドがsleepしているだけかと思います。
おそらく、executeが正常終了した後でも(そしてnewFixedThreadPoolの正常execute後でも)同じではないかと。

- eripong さん
ああ、たしかに！そちらのメソッドがScheduledExecutorServiceの本来実現したい機能ですもんね…

[argius]

eripongさん

コメントありがとうございます。
ちゃんとFuture取っていれば出るんですね。
そこも確認を忘れていました。
今後ScheduledExecutorService#schedule使うときはFutureを取得するようにします。

yukihaneさん

> そもそもUncaughtなExceptionは無い、というのが正確な表現ですかね。

おっしゃる通りで...
（ソースくらい読もう＞自分）

eripongさんのと合わせて考えるとよく分かりますね。

> おそらく、単純にプールされたワーカースレッドがsleepしているだけかと思います。

そういうことですね。

*****

最終的に、ただ勘違いしてただけじゃなくて、
よく分かっていなかったことが分かりました。

（それにしても、もうちょっと自分で何とかできていたはずなのにご指摘の点が何もできていないのがお恥ずかしい...）

お二人とも、的確なご教示ありがとうございました!