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

Да, пользоваться услугами исполнителя

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

record Technician ( int id , LocalDate eventStart , … ) {}

Создавайте экземпляры этих объектов Technician по мере того, как вы зацикливаете набор результатов из своего запроса.

Для каждого объекта Technician перейдите к конструктору класса, реализующего Callable. Метод run этого класса определяет работу, которую необходимо выполнить при обработке данных этой строки, переходе к вызовам веб-службы и т. д.

Callable возвращает значение. Давайте определим еще одну запись, чтобы сигнализировать об успехе/неуспехе и идентификаторе записи.

record TechnicianProcessingResult ( int id , boolean succeeded ) {}

Сделайте эту запись похожей на нашу Callable.

class ProcessTechnicianTask implements Callable< TechnicianProcessingResult > {

    private final Technician technician ;

    ProcessTechnicianTask( Technician t ) { // Constructor.
        this.technician = t ;
    }
 
    public TechnicianProcessingResult call() {
        System.out.println( "Processing technician Id " + this.technician.id );
        …
        return new TechnicianProcessingResult( this.technician.id , true ) ;
        … or …
        return new TechnicianProcessingResult( this.technician.id , false ) ;
    }
}

Создайте задачу для каждого объекта Technician, который вы создали для каждой строки, извлеченной из базы данных. Собери задания.

List< ProcessTechnicianTask > tasks = new ArrayList<>() ;
…
tasks.add( new ProcessTechnicianTask( nthTechnician ) ) ;

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

ExecutorService executorService = Executors.newFixedThreadPool( 5 ) ;
…
List< Future< TechnicianProcessingResult > > futures = executorService.invokeAll( tasks , 3 , TimeUnit.SECONDS ) ;

Обратите внимание на аргументы тайм-аута, которые срабатывают в случае, если что-то пойдет не так и выполнение ваших задач займет слишком много времени.

Проверьте список фьючерсов, чтобы увидеть, являются ли они сделано, и были ли они отменен, и проверьте их объект результата.

Вы хотите повторять это каждые три секунды. Так что также создайте однопоточный ScheduledExecutorService. Запланируйте повторяющуюся задачу, Runnable или Callable, которая выполняет вышеуказанную работу по запросу к базе данных, создает экземпляры Technician объектов, назначает каждый объект ProcessTechnicianTask, и все это передается нашей другой службе-исполнителю.

Обязательно корректно отключите объекты службы исполнителя. В противном случае их резервные пулы потоков могут продолжать работать бесконечно, как зомби ?‍♂️. См. шаблонный код в Javadoc.

Все это уже много раз обсуждалось на Stack Overflow. Так что ищите, чтобы узнать больше.

Вы, кажется, имели в виду этот подход. Но вы задавались вопросом, есть ли «более эффективные и быстрые способы». Нет, лучшего выхода я не вижу. Узким местом здесь являются сетевые вызовы к вашему API, предположительно вызовы веб-сервисов. Создание объектов записи, их сбор и отправка службам-исполнителям будут выполняться очень быстро по сравнению с потоками, ожидающими ответа от сетевых вызовов.

Проект Ткацкий станок

Единственное, что может значительно повысить производительность в вашем сценарии, — это виртуальные потоки и структурированный параллелизм, обещанные Проект Ткацкий станок.

В текущей версии Java каждый поток Java сопоставляется непосредственно с потоком хост-ОС. Каждый из ваших нескольких потоков будет бездействовать во время вызовов веб-служб, останавливая выполнение до тех пор, пока эти вызовы не вернутся. Эти потоки имеют большой вес, поэтому их не может быть очень много.

В Project Loom многие виртуальные потоки сопоставляются с каждым потоком хост-ОС. Эти виртуальные потоки легковесны, поэтому у нас могут быть тысячи и даже миллионы. Когда виртуальный поток блокируется, например, в ожидании возврата вызова веб-службы, этот виртуальный поток «припаркован»/«отключен» от потока хост-ОС, чтобы другой виртуальный поток мог использовать хост-поток. Таким образом, другие виртуальные потоки могут выполнять свою работу, пока предыдущий виртуальный поток ожидает возврата вызова своего веб-сервиса.

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

Проект Loom незакончен, но находится в активной разработке. Экспериментальные сборки доступен сейчас основаны на Java 19 раннего доступа. См. статьи, интервью и презентации с членами команды, включая Рона Пресслера и Алана Бейтмана.