В чем отличие асинхронного подхода от синхронного

Что проверяют

Различаете ли вы асинхронность, параллельность и неблокирующий ввод-вывод, которые часто сливают в одно. Следом спрашивают про CompletableFuture, про пул, в котором выполнится задача, и зачем асинхронность при виртуальных потоках.

Как отвечать

Синхронный вызов: код ждёт результата и только потом идёт дальше. Асинхронный: вызов сразу возвращает управление, а результат приходит позже через колбэк, Future или реактивный поток. Параллельность это другое измерение, одновременное выполнение на нескольких ядрах. Асинхронный код может работать в одном потоке, а синхронный выполняться параллельно в разных.

Рядом стоит пара «блокирующее и неблокирующее»: InputStream.read() держит поток всё время ожидания, и в модели «поток на запрос» тысяча медленных вызовов внешнего API означает тысячу занятых потоков Tomcat.

Инструменты в Java:

• CompletableFuture: supplyAsync, thenApply, thenCompose, allOf. Без явного Executor задачи уходят в ForkJoinPool.commonPool(), где потоков по числу ядер, и блокирующий вызов там съедает общий пул;
• реактивный стек: Spring WebFlux на Project Reactor и Netty, типы Mono и Flux. Требует неблокирующих драйверов по всей цепочке, например R2DBC вместо JDBC;
• виртуальные потоки: с Java 21 код пишется синхронно, а блокирующее ожидание не держит поток ОС. В Spring Boot 3.2+ включаются через spring.threads.virtual.enabled=true. Закрепление виртуального потока внутри synchronized убрали в Java 24.

Синхронный код проще читать и отлаживать, стек-трейс цельный. Асинхронность оправдана, когда много ожидания ввода-вывода и нужно одновременно сходить в несколько сервисов. На задачах, упирающихся в CPU, она выигрыша не даёт.

Где спотыкаются

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

Вызывают .get() или .join() сразу после supplyAsync. Получается синхронный код с лишним переключением потоков.

Теряют исключения: ошибка в CompletableFuture без exceptionally или handle молча оседает во фьючере, который никто не читает.