Что происходит, когда ты вызываешь метод `submit()` у экземпляра `ExecutorService`, если его очередь задач уже переполнена?

Обзор

Когда ты вызываешь submit() на экземпляре ExecutorService с переполненной очередью, система выбрасывает RejectedExecutionException, чтобы сигнализировать, что задача не может быть принята.

Поведение по умолчанию

ExecutorService использует политику отклонения для обработки этого сценария. По умолчанию он применяет AbortPolicy, которая сразу же выбрасывает RejectedExecutionException вместо того, чтобы ставить задачу в очередь или молча её отбрасывать.

Детали исключения

Это исключение указывает на то, что:

• Пул потоков достиг максимальной ёмкости
• Внутренняя очередь задач полностью заполнена
• На данный момент никаких дополнительных задач принято быть не может

Важные соображения

• Это ожидаемое и стандартное поведение для большинства реализаций ExecutorService
• Исключение служит чётким сигналом для вызывающего кода, что ресурсы исчерпаны
• Разработчики должны корректно обрабатывать это исключение в production-коде

Альтернативные политики отклонения

ExecutorService позволяет настраивать различные политики отклонения:

• AbortPolicy — выбрасывает исключение (по умолчанию)
• CallerRunsPolicy — выполняет задачу в потоке вызывающей стороны
• DiscardPolicy — молча отбрасывает задачу
• DiscardOldestPolicy — удаляет самую старую задачу и добавляет новую

Лучшая практика

При работе с ExecutorService реализуй грамотную обработку исключений, чтобы корректно справляться с ситуациями RejectedExecutionException. Если поведение по умолчанию не подходит для твоего приложения, рассмотри возможность написания собственной политики отклонения.