MiheiSV, да. Моё решение можно улучшить. На самом деле нам list/len не нужны.
Нужен фильтр и find_first. И опицональное результат. Я рассуждаю в терминах Scala/haskell.
Ты в теле вопроса так и не задал вопрос. Непонятно что именно ты хочешь ускорять? go-routine это технология. Вряд-ли ее можно ускорить. Можно ускорить твой код. А для этого надо понять где узкое место. Можешь узнать сколько времени работают твои Marhsall/Unmarshall? Println (кстати зачем он там?) Время отработки GET.
Вот технический момент. Если штук 100 из 3000 ендпоинтов будут отдавать Connection Timeout то что в этот момент будут чувсвовать твои вычислительные потоки? Это архитектурный вопрос.
Начни читать отсюда https://docs.oracle.com/en/java/javase/17/docs/api...
В стандартной документации достаточно полно изложены принципы и цели использования стримов. Про параллелизм пока забудь. Не надо это тебе. Обрати внимание как работают collect/reduce. И попробуй понять в чем разница между ними.
Я почему спрашиваю. Вы передали List. Уже потеряли время на генерации листа и не сэкономили на стриминге. Провал по сути. Здесь конешно можно обсуждать стримы но вы уже проиграли.
Суммарное время работы вашей функции это сумма времени загрузки листа из базы и генерации outputrecords. Причем outputrecords будут занимать 1% от общего времени.
А если мы работаем с БД то запросами ROLLUP/Cube мы можем просто собрать эту метрику среднего прямо в БД и отдать ответом вместе с основным телом.
Это по сути мой ответ на вопрос по поводу софистического и надуманного примера.
Streams с параллелизмом практически мало вам дают пользы. Просто другие затраты съедают в тысячи и миллионы раз больше времени. Вот такое мое рассуждение по этому вопросу.
А можно развернуть этот сценарий более широко? Я просто не понимаю какую угрозу мы тут устраняем.