Как происходит запуск метода с аннотацией @Scheduled и как работает scheduler

Что проверяют

Знаете ли вы, что планировщик Spring по умолчанию однопоточный и что произойдёт с расписанием, когда приложение поднято в нескольких экземплярах. Это две ошибки, которые ловятся уже на проде, а не в тестах.

Как отвечать

• @EnableScheduling включает ScheduledAnnotationBeanPostProcessor. На старте он обходит бины, находит методы с @Scheduled (без аргументов, обычно void) и регистрирует их в TaskScheduler. Приватный метод или объект, созданный через new, планировщик не увидит.
• Дефолтный TaskScheduler это пул из одного потока: все задачи приложения выстраиваются в очередь друг за другом, и одна долгая блокирует остальные. Лечится spring.task.scheduling.pool.size или своим ThreadPoolTaskScheduler.
• fixedDelay отсчитывает паузу от завершения предыдущего запуска, fixedRate от его начала. Параллельно один и тот же метод не запускается: если выполнение длиннее периода, следующие срабатывания просто опаздывают и идут подряд.
• cron в Spring состоит из шести полей, первое это секунды, в отличие от пятиполевого cron в Unix. Поддерживаются макросы вида @daily и параметр zone, иначе берётся часовой пояс сервера.

@Scheduled(cron = "0 0 3 * * *", zone = "Europe/Moscow")
public void cleanup() { archiveService.purgeOldRows(); }

• Исключение из задачи Spring логирует своим ErrorHandler, расписание продолжает работать. У голого ScheduledExecutorService необработанное исключение отменило бы все последующие запуски.
• В кластере задача выполнится в каждом экземпляре. Нужен внешний замок: ShedLock, Quartz с JDBC JobStore или выделенный инстанс.

Где спотыкаются

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

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

Забывают про несколько реплик, поэтому рассылка уходит пользователям дважды или трижды.

Не ставят таймаут на внешние вызовы внутри задачи: зависший запрос держит единственный поток планировщика бесконечно.