Как лучше всего создавать планировщики из следующего (или вашего варианта):
1) Для одного запланированного метода создайте один компонент и вызовите службу из этого метода:
@Component
public class MyScheduler {
private final MyService myService;
public MyScheduler(MyService myService) {
this.myService= myService;
}
@Scheduled(fixedDelay = 1L)
public void process() {
myService.startSomethig();
}
}
2) Создайте один компонент для всех запланированных методов и запустите службу для конкретного метода:
@Component
public class MySchedulers {
private final MyService1 myService1;
private final MyService2 myService2;
private final MyService3 myService3;
public MySchedulers (MyService1 myService1, MyService2 myService2, MyService3 myService3) {
this.myService1 = myService1;
this.myService2 = myService2;
this.myService3 = myService3;
}
@Scheduled(fixedDelay = 100L)
public void process() {
myService1.startSomethig();
}
@Scheduled(fixedDelay = 666L)
public void process() {
myService2.startAny();
}
@Scheduled(fixedDelay = 999L)
public void process() {
myService3.startAll();
}
}
3) Создайте расписанный метод в каждом конкретном сервисе:
@Service
public class MyServiceImpl implements MyService {
//filds, constructor
@Scheduled(fixedDelay = 100L)
public void process() {
startSomethig();
}
@Transactional
@Override
public void startSomethig() {
//...
}
Какой подход лучше? может есть другие? Буду рад услышать ваше мнение




Лучшего пути нет, все «зависит».
1). Это похоже на то, что я обычно делаю - я создаю класс с именем, заканчивающимся на «Job», например «GenerateReportJob», у которого есть запланированный метод, который часто просто вызывает другой класс обслуживания.
2). Если у вас есть запланированные задания, которые используют одни и те же зависимости, и их цель связана друг с другом - нет ничего плохого в том, чтобы поместить их в один и тот же класс. Но вам следует избегать создания только одного класса для всех возможных запланированных заданий в вашем приложении - он быстро превратится в огромный файл с множеством зависимостей, о которых трудно рассуждать.
3). Я избегаю помещать @Scheduled непосредственно в методы обслуживания, так как мне трудно найти все задания в приложении. Технически это работает, но, на мой взгляд, не подходит для разработчиков.
Я предпочитаю и реализовал в своем проекте второй метод.
Основная причина выбора этого способа - централизованное управление для всех периодических задач. Запланированные задачи в моем проекте интенсивно используются в базе данных, и таким образом я могу предотвратить дублирование выполняемых заданий.
Вторая причина - это читаемость кода. Соавторам проще находить недавно добавленные запланированные задачи.
Наконец, я согласен с Мачеем. Лучшая модель для вас зависит от ваших задач и вашей точки зрения, чтобы создать хорошую структуру для вашего собственного проекта.