Так понятно, спасибо.  Т.е. какие-нибудь green threads (вроде проект называется сейчас Fiber) решили бы проблему?

Будут- посмотрим.

В любом случае если операция блокирующая то любые потоки будут ждать. Тут именно нужен API который позволял бы отправить запрос, получить Future, а потом прочитать ответ когда нужен.

А когда он нужен? Обычно он нужен прямо сейчас

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

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

С синхронным апи вы так вообще не сделаете. Разве что по треду на каждый запрос руками создавать

Ну, так и делаем, если нагрузка позволяет. В большинстве enterprise приложений позволяет.

Ну сам не создаю, а вот connection pool создает по потоку на каждое соединение

Как это в коде выглядит?

Пусть есть два бэкенда с синхронным апи b1.get() и b2.get(). Как вы их запросите одновременно?

Через ExecutorService, туда Callable<MyResult>, оттуда рез-т.

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

Стоит отметить, что у асинхронности есть своя цена:
1. Код сильно усложняется. ТО что раньше было простым агоритмом станивится макаронами из очередей воткнутых друг в друга. Отлаживать проблемы в таком коде становится (значительно) сложнее.
2. Задержка ответа деградирует, иногда в сильно широких пределах.  Соотвественно если пределы ограничены, ( как например стандартное веб приложение с пользователем, АПИ для мобилки итп). То стоит подумать, насколько решаемая асинхронностью проблема реальна.  Борьда с такими задержками  требует непосредственных усилий разработчика, часто уже после отказов и инцидентов

Ну в этом случае мы переносим блокировку из основного потока в другой поток. Но получаем то же

почитал фитбэк, отзывы - огонь!

в js как-то научились сворачивать асинхронные стек трейсы и делать их читаемыми, нужно что-то подобное для корутин

иначе отладка будет адом

Дмитрий, о чем вы? О клиентском или серверном js?

Вопрос Тагира, как я его понял, был в том как мы без асинхронности одновременно опрашиваем несколько бэкендов, если нам для ответа нужны результаты от них всех.  Понятно, что ExecutorService породит дополнительные потоки и в них будут блокировки.  А мы в основном потоке будем ждать завершения тасков. Тем не менее - при умеренных нагрузках в реальных проектах этот подход отлично работает уже много лет.