2

先日、アプリケーションに重要なサービスを実装していましたが、それは何があっても実行し続けるはずです。そこで、次の構成を使用しました。

ScheduledExecutorService ses =
Executors.newSingleThreadScheduledExecutor();

//If the thread dies, another will take over
ses.scheduleAtFixedRate(importantPeriodicTask, 1, 1, TimeUnit.NANOSECONDS);

...importantPeriodicTaskがRuntimeExceptionまたはErrorを実際にスローすると、ScheduledExecutorServiceはこのタスクの実行を停止します（スケジュールされなくなります）。

もちろん、これはまさにjavadocが言っていることです。

タスクの実行で例外が発生した場合、それ以降の実行は抑制されます。

恥ずかしいのですが、なぜ作者ScheduledExecutorServiceがこのように実装したのか理解できませんでした。

確かに、RuntimeExceptionまたはError、特にErrorは通常はキャッチされません。しかし実際には、特にRuntimeExceptionの場合、実際のデプロイメントでは非常に一般的にスローされます。その特定の操作は失敗するはずですが、その孤立したエラーのためにアプリ自体が失敗しないことがほとんどの場合望ましいと思います。

ある周期的なタスクの抑制が他の種類の周期的なタスクに影響を与えないのは事実です。しかし、ほとんどの定期的なタスクの性質を考えると、これらのタスクは、孤立したタスクではなく、「サービス」として認識されるべきではありませんか？

つまり、その1つのインスタンスだけがimportantPeriodicTask失敗し、タスク自体のスケジュールが変更され続けるべきではないでしょうか。

4

1 に答える 1

3

私の意見では、現在の動作は合理的です。RuntimeExceptionsは通常、バグを指します。これらは、実際にはタスクのコードのどこにでも発生する可能性があります。たとえば、タスクがステートフルである場合、その状態に一貫性がなくなる可能性があり、その後の実行では予期しない動作が発生します。一般的に、私はそれ自体のバグから回復しようとするコードは好きではありませんが、それは私の意見です。

ScheduledExecutorServiceの動作を変更する場合は、次の一般的なソリューションを確認してください。

http://www.javaspecialists.eu/archive/Issue154.html

于 2010-07-22T12:58:53.970 に答える