Максимальное количество асинхронных вызовов одновременно с использованием Java

Question

У меня есть асинхронный метод, который мне нужно вызывать несколько раз. Есть ли ограничение, что я могу иметь только эти много вызовов одновременно? если да, то каков наилучший способ ограничения. Thread.sleep в порядке или есть другой способ?

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

UPDATE пример кода

 @Async
        public void download(){
    //download file from server
    }
    public void callDownload(){
    for( int i =0; i <100000; i++)
      download();
    }

Заранее спасибо!

Answer 1

ОК, так что мы на самом деле говорим об асинхронных вызовах, реализованных с использованием механизма Spring @async.

Согласно https://www.baeldung.com/spring-async:

Проще говоря - аннотирование метода компонента с помощью @Async заставит его выполнить в отдельном потоке ; то есть вызывающая сторона не будет ждать завершения вызванного метода.

и

По умолчанию Spring использует SimpleAsyncTaskExecutor для фактического выполнения этих методов асинхронно.

Глядя на javadocs для SimpleAsyncTaskExecutor, мы видим:

Реализация TaskExecutor, которая запускает новый поток для каждой задачи, выполняя его асинхронно.

Поддерживает ограничение параллельных потоков через свойство компонента "concurrencyLimit". По умолчанию количество одновременных потоков не ограничено.

ПРИМЕЧАНИЕ. В этой реализации не используются потоки! Вместо этого рассмотрим реализацию TaskExecutor с пулом потоков, в частности, для выполнения большого количества краткосрочных задач.

Итак, из этого мы можем сделать вывод (если вы не выполнили какую-либо дополнительную настройку, о которой вы не упомянули):

1. Каждый из ваших асинхронных вызовов использует отдельный поток.
2. Нет пула потоков для повторного использования потоков.
3. Механизм не ограничивает количество создаваемых потоков.

Создание потока стоит дорого, и каждый поток потребляет значительный объем памяти. Так что я ожидаю, что происходит то, что вы перегружаете JVM чрезмерным количеством потоков, и это приводит к остановке. (Либо из-за гибели спирали ГХ, перегрузки виртуальной памяти или, возможно, перегрузки сети из-за попытки сделать слишком много загрузок одновременно.)

По сути, этот наивный подход не будет масштабироваться. Лучше было бы использовать ExecutorService с ограниченным пулом потоков и отправлять запросы на загрузку в виде задач. Служба executor поставит задачи в очередь и отправит их в свой пул рабочих потоков. Вы должны настроить размер пула потоков так, чтобы он не перегружал вашу локальную память / вычисления, ваше сетевое соединение ... и удаленные серверы, которые вы НАРУШАЕТЕ при параллельных загрузках.

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

Answer 2

Есть две части с асинхронными вызовами. Клиент и сервер (может быть).

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

2. Это также будет зависеть от того, какой тип вызова вы делаете - это сервер / сетевой вызов? Делаете ли вы запрос к базе данных, очереди и т. Д. Эти системы могут иметь собственное ограничение на количество запросов, которые они могут обрабатывать параллельно и блокировать остальную часть вызова. Это зависит.

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

Всегда полезно разумно ограничить асинхронный параллельный вызов в зависимости от количества доступных потоков / процессора.