---

🟢 Junior Level

Методы join() и get() предназначены для одной цели: они переводят текущий поток в режим ожидания (блокируют его) до тех пор, пока асинхронное вычисление в CompletableFuture не завершится, после чего возвращают полученный результат или выбрасывают исключение.

Главное практическое отличие: Сигнатура исключений

Метод	Тип исключений	Зачем нужен
get()	Checked (InterruptedException, ExecutionException)	Пришел из интерфейса java.util.concurrent.Future (Java 5). Требует явного блока try-catch или throws.
join()	Unchecked (CompletionException)	Добавлен в CompletableFuture (Java 8) специально для удобного использования внутри лямбда-выражений и Stream API без нагромождения boilerplate-кода.

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> "Hello, World!");

// 1. Использование get() — классический Java 5 стиль с обработкой checked exceptions
try {
    String res = future.get();
} catch (InterruptedException e) {
    Thread.currentThread().interrupt(); // восстанавливаем флаг прерывания
} catch (ExecutionException e) {
    log.error("Task failed: ", e.getCause());
}

// 2. Использование join() — современный функциональный стиль
String res = future.join(); // выбрасывает unchecked CompletionException при ошибке

Использование в Stream API

join() незаменим, когда нужно дождаться результатов пачки асинхронных задач в потоке:

List<CompletableFuture<User>> futures = ids.stream()
    .map(userService::fetchUserAsync)
    .toList();

// Благодаря unchecked CompletionException, join() чисто ложится в лямбду:
List<User> users = futures.stream()
    .map(CompletableFuture::join) // с get() здесь потребовался бы громоздкий try-catch
    .toList();

---

🟡 Middle Level

1. Наличие таймаута: get(timeout) vs join()

Метод Future.get имеет перегруженную версию с таймаутом:

// Блокирует поток максимум на 2 секунды; выбрасывает TimeoutException, если не успел
String result = future.get(2, TimeUnit.SECONDS);

У метода join() нет перегрузки с таймаутом в стандартном API. Если вызвать join() на зависшей задаче, вызывающий поток зависнет навсегда.

Начиная с Java 9, эту проблему решают цепочечным вызовом .orTimeout() перед .join():

// Идиоматичный современный вариант без checked exceptions:
String result = future.orTimeout(2, TimeUnit.SECONDS).join();
// При превышении лимита выбросит CompletionException с причиной TimeoutException

2. Специфика распаковки исключений

При сбое фоновой задачи методы упаковывают оригинальное исключение (например, IllegalStateException) по-разному:

CompletableFuture<String> failing = CompletableFuture.failedFuture(new IllegalArgumentException("Invalid ID"));

// При вызове get():
try {
    failing.get();
} catch (ExecutionException e) {
    Throwable original = e.getCause(); // IllegalArgumentException
}

// При вызове join():
try {
    failing.join();
} catch (CompletionException e) {
    Throwable original = e.getCause(); // IllegalArgumentException
}

[!IMPORTANT] Исключение-сюрприз — CancellationException: Если задача была отменена через future.cancel(true), оба метода — и get(), и join() — выбрасывают CancellationException напрямую как unchecked runtime exception, без оборачивания в ExecutionException или CompletionException!

---

🔴 Senior Level

Анатомия исходного кода JDK: Interruptible vs Non-Interruptible ожидания

Разница между get() и join() не ограничивается типами исключений. В исходном коде CompletableFuture (JDK) они по-разному взаимодействуют с механизмом прерывания потоков (Thread Interruption):

// Исходный код CompletableFuture в OpenJDK:
public T get() throws InterruptedException, ExecutionException {
    Object r;
    if ((r = result) == null)
        r = waitingGet(true); // true -> INTERRUPTIBLE
    return (T) reportGet(r);
}

public T join() {
    Object r;
    if ((r = result) == null)
        r = waitingGet(false); // false -> UNINTERRUPTIBLE
    return (T) reportJoin(r);
}

Внутренний цикл waitingGet(boolean interruptible)

1. get() вызывает waitingGet(true) (прерываемый режим): Если поток, заблокированный в get(), получает сигнал thread.interrupt(), он немедленно прекращает ожидание, удаляет свой узел из очереди ожидания (Signaller) и выбрасывает InterruptedException.
2. join() вызывает waitingGet(false) (непрерываемый режим): Если поток, ожидающий в join(), прерывается через thread.interrupt(), он продолжает спать и ждать завершения задачи! Он запоминает факт прерывания во внутреннем флаге interrupted = true. Только когда CompletableFuture будет окончательно завершен другим потоком, waitingGet восстанавливает статус прерывания текущего потока:

   if (interrupted)
       Thread.currentThread().interrupt(); // Восстановление статуса прерывания
   

   После чего reportJoin(r) возвращает результат или бросает CompletionException.

Логика распаковки: reportGet vs reportJoin

Внутренний результат завершения хранится в поле volatile Object result в виде специальной обертки AltResult:

// Внутренняя реализация распаковки в JDK:
private static Object reportGet(Object r) throws ExecutionException {
    if (r instanceof AltResult) {
        Throwable x = ((AltResult)r).ex;
        if (x == null) return null; // NIL result
        if (x instanceof CancellationException) throw (CancellationException)x;
        Throwable cause;
        // Разворачивает промежуточный CompletionException, если он есть!
        if ((x instanceof CompletionException) && (cause = x.getCause()) != null)
            x = cause;
        throw new ExecutionException(x); // Оборачивает в ExecutionException
    }
    return r;
}

private static Object reportJoin(Object r) {
    if (r instanceof AltResult) {
        Throwable x = ((AltResult)r).ex;
        if (x == null) return null;
        if (x instanceof CancellationException) throw (CancellationException)x;
        if (x instanceof CompletionException) throw (CompletionException)x;
        throw new CompletionException(x); // Оборачивает любое иное Throwable в CompletionException
    }
    return r;
}

Обратите внимание на тонкую деталь: если исходная стадия уже была завершена с CompletionException, reportJoin пробрасывает его как есть, не создавая повторной вложенности new CompletionException(new CompletionException(...)). В то же время reportGet всегда разворачивает CompletionException и кладет в ExecutionException оригинальный cause.

Быстрый путь (Fast-path) без блокировок

Если result != null на момент входа в get() или join(), никакой парковки потока не происходит. Метод моментально считывает volatile-переменную result и возвращает значение за единицы наносекунд. Именно поэтому вызов .join() внутри коллбэков после CompletableFuture.allOf(...) абсолютно бесплатен и не блокирует системные потоки.

---

4 Tricky Questions

1. Что произойдет, если прервать поток (thread.interrupt()), заблокированный внутри cf.join() vs cf.get()?

Ответ:

• Поток, ожидающий в get(), немедленно проснется, очистит свой статус прерывания и выбросит InterruptedException.
• Поток, ожидающий в join(), не прервет свое ожидание. Он продолжит находиться в состоянии ожидания (блокировки/парковки) до тех пор, пока cf не будет физически завершен (успешно или с ошибкой). Только после наступления результата метод join() завершится, восстановит статус прерывания вызывающего потока через Thread.currentThread().interrupt() и вернет значение (или выбросит CompletionException).

2. Бросает ли get() всегда ExecutionException при ошибке, а join() — CompletionException? Что происходит при отмене через cancel()?

Ответ: Нет, не всегда. Если CompletableFuture был отменен вызовом cancel(true) или cancel(false), внутренний результат помечается как AltResult(new CancellationException()).

В этом случае и get(), и join() выбрасывают напрямую CancellationException (наследник IllegalStateException $\rightarrow$ RuntimeException), без оборачивания в ExecutionException или CompletionException. Это исключение не проверяемое (unchecked) в обоих методах!

3. Если внутри цепочки брошен MyCustomBusinessException, в каком виде его получат get() и join()? Сколько уровней вложенности будет в стектрейсе?

Ответ:

• При вызове join(): будет выброшен CompletionException, у которого e.getCause() является экземпляром MyCustomBusinessException. Если цепочка состояла из нескольких этапов, reportJoin не наращивает вложенность и оставляет один уровень CompletionException.
• При вызове get(): метод reportGet внутри JDK явно проверяет: если пойманная ошибка — CompletionException, он берет ее getCause() и только затем упаковывает в ExecutionException. Поэтому e.getCause() у ExecutionException вернет напрямую MyCustomBusinessException, минуя промежуточный CompletionException.

4. Безопасно ли вызывать .join() внутри коллбэка allOf(...).thenApply(...)? Блокирует ли он поток в этот момент?

Ответ: Да, это абсолютно безопасно и является стандартным идиоматичным паттерном в Java.

Метод CompletableFuture.allOf(f1, f2) завершается только тогда, когда все переданные стадии f1 и f2 перешли в состояние Completed (или Failed). Поэтому к моменту исполнения стадии thenApply поле result у f1 и f2 гарантированно не равно null. Вызов f1.join() отрабатывает по быстрому пути (fast-path): просто считывает volatile Object result без обращения к планировщику, блокировки или парковки потока (ForkJoinPool.managedBlock даже не вызывается).

---

🎯 Шпаргалка для интервью

Сводная шпаргалка различий

Характеристика	Future.get()	CompletableFuture.join()
Происхождение	Java 5 (java.util.concurrent.Future)	Java 8 (CompletableFuture)
Сигнатура исключений	Checked (InterruptedException, ExecutionException)	Unchecked (CompletionException)
Реакция на Thread.interrupt()	Немедленно выбрасывает InterruptedException	Ждет завершения задачи, затем восстанавливает флаг interrupt
Поддержка таймаута	Есть встроенная перегрузка get(timeout, unit)	Нет (требуется .orTimeout(timeout, unit).join())
Поведение при cancel()	Бросает CancellationException (unchecked)	Бросает CancellationException (unchecked)
Применение в Stream API	Неудобен (требует try-catch внутри лямбды)	Идеален для map(CompletableFuture::join)

Ключевые правила на собеседовании

1. В тестах и Stream API: используйте .join(), чтобы не загромождать код сигнатурами checked exceptions.
2. В боевом production коде: никогда не вызывайте голый join() без таймаута! Либо используйте get(timeout, unit), либо orTimeout(...).join().
3. Обработка ошибок: помните, что join() выбрасывает CompletionException, а оригинальную причину нужно извлекать через .getCause().

Антипаттерны

• ❌ Считать join() неблокирующим методом: join() блокирует текущий поток точно так же, как и get().
• ❌ Попытка прервать зависший join() через thread.interrupt(): поток продолжит висеть намертво, так как waitingGet(false) игнорирует прерывание во время ожидания.
• ❌ Блокирующий join() на потоке ввода-вывода (Netty event-loop): это парализует обработку десятков тысяч сетевых соединений.

Связанные темы

• Что такое блокирующий код и как его отличить от неблокирующего
• Как реализовать timeout для CompletableFuture
• Что делает метод orTimeout() в Java 9+
• Как тестировать код с CompletableFuture