ScheduledExecutorService с возможностью удаления потерян

Question

Считайте, что я запланировал Runnable для периодического выполнения с ScheduledExecutorService, и возникает некоторая системная ошибка, такая как OutOfMemory. Будет тихо проглочен.

scheduler.scheduleWithFixedDelay(new Runnable() {
                    @Override
                    public void run() {
                      throw new OutOfMemoryError(); // Swallowed
                    }
                }, 0, delay, TimeUnit.SECONDS);

Это нормально?

Почему он не распространяется на контейнер?

Как правильно обрабатывать такие ошибки?

Спасибо!

Answer 1

OutOfMemoryError, как и любой подтип Error, восстановить нельзя, они, как правило, фатальны для вашей программы.На самом деле не имеет значения, пытаетесь ли вы поймать это или нет, ваша программа не работает.

Если, однако, вы имеете в виду Exception, а не Error, то у вас есть 2 варианта:

1. Поймать исключение из метода run() вашей задачи.
2. Вызов get() для Future(), возвращаемого scheduleWithFixedDelay().Это распространит исключение обратно в отправляющий поток, но будет блокироваться до тех пор, пока это не произойдет.

Answer 2

Метод вернет экземпляр ScheduledFuture, и методы get (с таймаутом или без него) сгенерируют исключение ExecutionException с вашей OutOfMemoryError в качестве причины.

Answer 3

Вы можете использовать VerboseRunnable класс из jcabi-log , который перехватывает все исключения и регистрирует их:

import com.jcabi.log.VerboseRunnable;
Runnable runnable = new VerboseRunnable(
  Runnable() {
    public void run() { 
      // do business logic, may Exception occurs
    }
  },
  true // it means that all exceptions will be swallowed and logged
);

Теперь, когда кто-то звонит runnable.run(), исключений не выдается. Вместо этого они проглатываются и регистрируются (в SLF4J).

Answer 4

Лично я бы предоставил вашему объекту какой-то механизм сообщения об исключениях, а не ожидал, что среда для их обработки.Подумайте о слушателе исключения или подобном.

Для ома мало что можно сделать.

Эти исполнители ели там, чтобы выполнить ваши вещи, чтобы не обрабатывать все возможные проблемы, которые могут возникнуть в вашем коде!

Answer 5

Класс ListenableFuture из guava может быть полезен здесь.

При этом вы можете создать задачу обработчика исключений, которая регистрирует ошибку и затем пытается перезапустить сбойtask.

Вам все еще нужен спящий поток, чтобы отслеживать исключения, но вам нужен только один поток глобальных обработчиков исключений для всего процесса (а не один для каждой запланированной задачи.)