Блог

ScheduledThreadPoolExecutor extends ThreadPoolExecutor , но с меньшим количеством конструкторов, ScheduledThreadPoolExecutor предоставляет бесконечный DelayQueue, так что, если я отправлю слишком много задач, это может вызвать jvm-ООМ, почему он не предоставляет конечную очередь и политику отклонения (отклонять, когда не удается отправить новую задачу)?

Почему он не предоставляет конечную очередь и политику отклонения (отклонять, когда не удается отправить новую задачу)?

Вам нужно было бы спросить разработчиков, но тот факт, что они решили не поддерживать это, предполагает, что они думали, что это не будет полезно. (Или, по крайней мере, не достаточно полезно, чтобы оправдать дополнительную сложность.)

Есть и другая причина. Реализация ScheduledThreadPoolExecutor зависит от очереди, возвращающей элементы в правильном порядке. Если вы посмотрите на исходный код, вы увидите, что для этого используется пользовательский класс queue. Есть комментарий, в котором говорится следующее:

Использование пользовательской очереди ( DelayedWorkQueue ), варианта unbounded DelayQueue . Отсутствие ограничения емкости и тот факт, что corePoolSize и maximumPoolSize фактически идентичны, упрощает некоторые механизмы выполнения (см. delayedExecute ) по сравнению с ThreadPoolExecutor .

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

Наконец, если вы хотите, чтобы ваше приложение накладывало ограничение на размер очереди задержки, вы могли бы использовать yourPool.getQueue().length() для проверки длины очереди перед планированием новой задачи.