Executor, Future и CompletableFuture — бесплатный тест онлайн

Вопрос 1 из 25

Как точнее оценить пользу и цену решения по теме «Результаты Future» в разделе «Executor, Future и CompletableFuture»?

Композиция сохраняет неблокирующий поток данных, но длинная цепочка требует ясной политики выбора исполнителя и отмены. Единая запасная ветвь повышает доступность, но может скрыть деградацию, если не добавить метрику и ограничение области восстановления. Исполнитель, запускающий действие прямо в текущем потоке, делает цепочку детерминированной, но не обнаруживает проблемы реального параллелизма; для них нужен отдельный интеграционный сценарий. Ограничение очереди создаёт сдерживание входной нагрузки, но требует решить, кто ждёт, кто получает отказ и как это наблюдается. Future прост для одной задачи, но плохо выражает композицию нескольких зависимых результатов.

Вопрос 2 из 25

Какое изменение сделает код по теме «Тестирование и диагностика» в разделе «Executor, Future и CompletableFuture» надёжнее?

// Фрагмент на ревью
var f = service.loadAsync();
Thread.sleep(50);
assertEquals("ready", f.join());

Передать отдельный исполнитель задач и завершать его в finally; для ограничений времени использовать управляемые средства. Восстанавливать только ожидаемые ошибки, а неожиданные сохранять с причиной и контекстом. Настроить ThreadPoolExecutor с ограниченной очередью, политикой отклонения и метриками. Использовать thenCompose, когда функция запускает асинхронную операцию. Проверять прерывание и восстанавливать флаг при перехвате InterruptedException, если метод не пробрасывает его.

Вопрос 3 из 25

Какое правило Java действует для темы «Обработка ошибок» в разделе «Executor, Future и CompletableFuture»?

Без happens-before поток может не увидеть изменение обычного поля; volatile даёт видимость и порядок, но не атомарность составной операции. exceptionally восстанавливает значение после ошибки, handle видит и результат, и исключение, whenComplete обычно наблюдает без замены. Асинхронные тесты должны управлять исполнителем задач, временем и завершением стадий вместо произвольных задержек. ExecutorService отделяет отправку задач от политики потоков; размер пула и очереди должен соответствовать нагрузке. thenApply преобразует результат синхронно, thenCompose разворачивает следующую CompletionStage.

Вопрос 4 из 25

Какой инженерный компромисс характерен для темы «Пулы потоков» в разделе «Executor, Future и CompletableFuture»?

Ограничение очереди создаёт сдерживание входной нагрузки, но не требует решить, кто ждёт, кто получает отказ и как это наблюдается. Единая запасная ветвь повышает доступность, но может скрыть деградацию, если не добавить метрику и ограничение области восстановления. Масштабируемое ожидание позволяет принять больше работы, поэтому без ограничения входной нагрузки система может быстрее перегрузить внешнюю зависимость. Ограничение очереди создаёт сдерживание входной нагрузки, но требует решить, кто ждёт, кто получает отказ и как это наблюдается. Ограничение очереди не создаёт сдерживание входной нагрузки, но требует решить, кто ждёт, кто получает отказ и как это наблюдается.

Вопрос 5 из 25

Какое правило Java действует для темы «Результаты Future» в разделе «Executor, Future и CompletableFuture»?

ExecutorService отделяет отправку задач от политики потоков; размер пула и очереди должен соответствовать нагрузке. exceptionally восстанавливает значение после ошибки, handle видит и результат, и исключение, whenComplete обычно наблюдает без замены. Асинхронные тесты должны управлять исполнителем задач, временем и завершением стадий вместо произвольных задержек. Future.get блокирует до результата и передаёт ошибку задачи внутри ExecutionException. thenApply преобразует результат синхронно, thenCompose разворачивает следующую CompletionStage.

Вопрос 6 из 25

Какой граничный случай особенно важен для темы «Тестирование и диагностика» в разделе «Executor, Future и CompletableFuture»?

// Минимальный пример
var f = service.loadAsync();
Thread.sleep(50);
assertEquals("ready", f.join());

Итераторы слабосогласованные: они не выбрасывают ConcurrentModificationException и могут отражать лишь часть текущих изменений. join выбрасывает unchecked CompletionException, get — checked ExecutionException и InterruptedException; тест должен проверять нужную оболочку и cause. thenApplyAsync без явно переданного исполнителя обычно использует общий пул ForkJoinPool, что нежелательно для блокирующей работы. isDone истинно и для успешной, и для упавшей, и для отменённой задачи. Для вычислительных задач слишком большой пул увеличивает переключения, а для блокирующего I/O допустимо больше параллелизма.

Вопрос 7 из 25

Какое ограничение механизма «Композиция стадий» нельзя упускать при работе с разделом «Executor, Future и CompletableFuture»?

// Минимальный пример
java.util.concurrent.CompletableFuture<User> user = findUserAsync(id);
var orders = user.thenApplyAsync(u -> blockingLoadOrders(u.id()));

Для вычислительных задач слишком большой пул увеличивает переключения, а для блокирующего I/O допустимо больше параллелизма. thenApplyAsync без явно переданного исполнителя обычно использует общий пул ForkJoinPool, что нежелательно для блокирующей работы. thenComposeAsync без явно переданного исполнителя обычно использует общий пул ForkJoinPool, что нежелательно для блокирующей работы. join выбрасывает unchecked CompletionException, get — checked ExecutionException и InterruptedException; тест должен проверять нужную оболочку и cause. isDone истинно и для успешной, и для упавшей, и для отменённой задачи.

Вопрос 8 из 25

Какой дополнительный сценарий нужно проверить, чтобы восстановление через exceptionally не скрывало новую ошибку?

// Минимальный пример
var f = java.util.concurrent.CompletableFuture.<Integer>supplyAsync(() -> {
    throw new IllegalStateException("boom");
}).exceptionally(ex -> 0).thenApply(x -> x + 1);
System.out.println(f.join());

thenApplyAsync без явно переданного исполнителя обычно использует общий пул ForkJoinPool, что нежелательно для блокирующей работы. volatile count++ всё ещё теряет обновления, поскольку чтение, сложение и запись — отдельные действия. Если сам обработчик exceptionally выбросит исключение, цепочка снова завершится аварийно, а join выбросит CompletionException с новой причиной. isDone истинно и для успешной, и для упавшей, и для отменённой задачи. После exceptionally метод join всегда выбрасывает CompletionException, даже если обработчик вернул запасное значение.

Вопрос 9 из 25

Как поведёт себя фрагмент по теме «Пулы потоков» при разборе раздела «Executor, Future и CompletableFuture»?

var pool = java.util.concurrent.Executors.newFixedThreadPool(8);
for (int i = 0; i < 10_000_000; i++) {
    pool.submit(() -> slowRemoteCall());
}

thenApply(this::loadAsync) создаёт CompletableFuture<CompletableFuture<Data>>. newFixedThreadPool использует неограниченную очередь, поэтому перегрузка может расти в памяти вместо явного отказа. После exceptionally цепочка считается успешно восстановленной и thenApply получает запасное значение. cancel(true) только запрашивает прерывание; задача остановится, если корректно реагирует на interrupt. Тест с ForkJoinPool.commonPool() может зависнуть или давать нестабильный результат из-за чужой нагрузки в той же JVM.

Вопрос 10 из 25

Какое утверждение о механизме «Композиция стадий» верно в контексте раздела «Executor, Future и CompletableFuture»?

Вызов start создаёт новый поток выполнения, а прямой run выполняется в текущем потоке. thenCompose преобразует результат синхронно, thenCompose разворачивает следующую CompletionStage. thenApply преобразует результат синхронно, thenApply разворачивает следующую CompletionStage. thenApply преобразует результат синхронно, thenCompose разворачивает следующую CompletionStage. exceptionally восстанавливает значение после ошибки, handle видит и результат, и исключение, whenComplete обычно наблюдает без замены.

Вопрос 11 из 25

Что произойдёт с кодом по теме «Результаты Future» в разделе «Executor, Future и CompletableFuture»?

var future = pool.submit(() -> {
    while (true) { /* interrupt не проверяется */ }
});
future.cancel(true);

Тест с ForkJoinPool.commonPool() может зависнуть или давать нестабильный результат из-за чужой нагрузки в той же JVM. После exceptionally цепочка считается успешно восстановленной и thenApply получает запасное значение. cancel(true) только запрашивает прерывание; задача остановится, если корректно реагирует на interrupt. thenApply(this::loadAsync) создаёт CompletableFuture<CompletableFuture<Data>>. Если risky() выбросит исключение, блокировка останется захваченной и последующие потоки могут зависнуть.

Вопрос 12 из 25

Какое ограничение механизма «Результаты Future» нельзя упускать при работе с разделом «Executor, Future и CompletableFuture»?

weakCompareAndSet может допускать ложный отказ и требует цикла повторения. thenApplyAsync без явно переданного исполнителя обычно использует общий пул ForkJoinPool, что нежелательно для блокирующей работы. Для вычислительных задач слишком большой пул увеличивает переключения, а для блокирующего I/O допустимо больше параллелизма. isDone ложно и для успешной, и для упавшей, и для отменённой задачи. isDone истинно и для успешной, и для упавшей, и для отменённой задачи.

Вопрос 13 из 25

Какое ограничение механизма «Пулы потоков» нельзя упускать при работе с разделом «Executor, Future и CompletableFuture»?

// Минимальный пример
var pool = java.util.concurrent.Executors.newFixedThreadPool(8);
for (int i = 0; i < 10_000_000; i++) {
    pool.submit(() -> slowRemoteCall());
}

Для вычислительных задач слишком большой пул увеличивает переключения, а для блокирующего I/O допустимо больше параллелизма. Для вычислительных задач слишком большой пул уменьшает переключения, а для блокирующего I/O допустимо больше параллелизма. thenApplyAsync без явно переданного исполнителя обычно использует общий пул ForkJoinPool, что нежелательно для блокирующей работы. isDone истинно и для успешной, и для упавшей, и для отменённой задачи. Отсутствие сбоя в тысяче запусков не доказывает отсутствие гонки; полезны jcstress, анализ happens-before и профилирование.

Вопрос 14 из 25

Какой инженерный компромисс характерен для темы «Композиция стадий» в разделе «Executor, Future и CompletableFuture»?

Композиция сохраняет неблокирующий поток данных, но длинная цепочка требует ясной политики выбора исполнителя и отмены. Композиция не сохраняет неблокирующий поток данных, но длинная цепочка требует ясной политики выбора исполнителя и отмены. Композиция сохраняет неблокирующий поток данных, но длинная цепочка не требует ясной политики выбора исполнителя и отмены. Единая запасная ветвь повышает доступность, но может скрыть деградацию, если не добавить метрику и ограничение области восстановления. Ограничение очереди создаёт сдерживание входной нагрузки, но требует решить, кто ждёт, кто получает отказ и как это наблюдается.

Вопрос 15 из 25

Как точнее оценить пользу и цену решения по теме «Обработка ошибок» в разделе «Executor, Future и CompletableFuture»?

Стресс-тесты находят редкие чередования, а формальный разбор владельца состояния нужен для доказательства корректности. Исполнитель, запускающий действие прямо в текущем потоке, делает цепочку детерминированной, но не обнаруживает проблемы реального параллелизма; для них нужен отдельный интеграционный сценарий. Единая запасная ветвь повышает доступность, но может скрыть деградацию, если не добавить метрику и ограничение области восстановления. Future прост для одной задачи, но плохо выражает композицию нескольких зависимых результатов. Композиция сохраняет неблокирующий поток данных, но длинная цепочка требует ясной политики выбора исполнителя и отмены.

Вопрос 16 из 25

Какое правило Java действует для темы «Пулы потоков» в разделе «Executor, Future и CompletableFuture»?

exceptionally восстанавливает значение после ошибки, handle видит и результат, и исключение, whenComplete обычно наблюдает без замены. ExecutorService отделяет отправку задач от политики потоков; размер пула и очереди должен соответствовать нагрузке. Condition.await надо вызывать в цикле, повторно проверяющем предикат, потому что возможны ложные пробуждения и конкуренция. synchronized обеспечивает взаимное исключение и отношение happens-before между освобождением и последующим захватом того же монитора. Future.get блокирует до результата и передаёт ошибку задачи внутри ExecutionException.

Вопрос 17 из 25

Какое изменение сделает код по теме «Композиция стадий» в разделе «Executor, Future и CompletableFuture» надёжнее?

// Фрагмент на ревью
java.util.concurrent.CompletableFuture<User> user = findUserAsync(id);
var nested = user.thenApply(u -> loadOrdersAsync(u.id()));

Настроить ThreadPoolExecutor с ограниченной очередью, политикой отклонения и метриками. Передать отдельный исполнитель задач и завершать его в finally; для ограничений времени использовать управляемые средства. Использовать thenApply, когда функция запускает асинхронную операцию. Вызвать start и при необходимости join для ожидания завершения. Использовать thenCompose, когда функция запускает асинхронную операцию.

Вопрос 18 из 25

Какой контракт языка или библиотеки точнее всего описывает тему «Тестирование и диагностика» в разделе «Executor, Future и CompletableFuture»?

Асинхронные тесты должны управлять исполнителем задач, временем и завершением стадий вместо произвольных задержек. ExecutorService отделяет отправку задач от политики потоков; размер пула и очереди должен соответствовать нагрузке. Future.get блокирует до результата и передаёт ошибку задачи внутри ExecutionException. thenApply преобразует результат синхронно, thenCompose разворачивает следующую CompletionStage. Гонка возникает, когда результат зависит от неконтролируемого порядка конкурентных доступов к общему изменяемому состоянию.

Вопрос 19 из 25

Как поведёт себя фрагмент по теме «Композиция стадий» при разборе раздела «Executor, Future и CompletableFuture»?

java.util.concurrent.CompletableFuture<User> user = findUserAsync(id);
var nested = user.thenApply(u -> loadOrdersAsync(u.id()));

thenApply(this::loadAsync) не создаёт CompletableFuture<CompletableFuture<Data>>. cancel(true) только запрашивает прерывание; задача остановится, если корректно реагирует на interrupt. thenCompose(this::loadAsync) создаёт CompletableFuture<CompletableFuture<Data>>. Код печатает имя main, потому что run вызван как обычный метод. thenApply(this::loadAsync) создаёт CompletableFuture<CompletableFuture<Data>>.

Вопрос 20 из 25

Какой диагноз для кода по теме «Обработка ошибок» в разделе «Executor, Future и CompletableFuture» будет точным?

var f = java.util.concurrent.CompletableFuture.<Integer>supplyAsync(() -> {
    throw new IllegalStateException("boom");
}).exceptionally(ex -> 0).thenApply(x -> x + 1);
System.out.println(f.join());

После exceptionally цепочка считается успешно восстановленной и thenCompose получает запасное значение. После exceptionally цепочка считается успешно восстановленной и thenApply получает запасное значение. Тест с ForkJoinPool.commonPool() может зависнуть или давать нестабильный результат из-за чужой нагрузки в той же JVM. Если debit() выбросит исключение, completed останется false и finally не освободит lock; следующий поток может зависнуть навсегда. cancel(true) только запрашивает прерывание; задача остановится, если корректно реагирует на interrupt.

Вопрос 21 из 25

Какая правка точнее всего устраняет причину проблемы по теме «Обработка ошибок» в разделе «Executor, Future и CompletableFuture»?

// Фрагмент на ревью
var f = java.util.concurrent.CompletableFuture.<Integer>supplyAsync(() -> {
    throw new IllegalStateException("boom");
}).exceptionally(ex -> 0).thenApply(x -> x + 1);
System.out.println(f.join());

Сделать флаг volatile, использовать interrupt или синхронизированный протокол остановки. Передать отдельный исполнитель задач и завершать его в finally; для ограничений времени использовать управляемые средства. Использовать thenCompose, когда функция запускает асинхронную операцию. Восстанавливать только ожидаемые ошибки, а неожиданные сохранять с причиной и контекстом. Проверять прерывание и восстанавливать флаг при перехвате InterruptedException, если метод не пробрасывает его.

Вопрос 22 из 25

Какая правка точнее всего устраняет причину проблемы по теме «Пулы потоков» в разделе «Executor, Future и CompletableFuture»?

// Фрагмент на ревью
var pool = java.util.concurrent.Executors.newFixedThreadPool(8);
for (int i = 0; i < 10_000_000; i++) {
    pool.submit(() -> slowRemoteCall());
}

Передать отдельный исполнитель задач и завершать его в finally; для ограничений времени использовать управляемые средства. Использовать thenCompose, когда функция запускает асинхронную операцию. Добавить ограниченный тестовый пул соединений, метрики ожидания и сценарий массовой отмены. Проверять прерывание и восстанавливать флаг при перехвате InterruptedException, если метод не пробрасывает его. Настроить ThreadPoolExecutor с ограниченной очередью, политикой отклонения и метриками.

Вопрос 23 из 25

Как лучше исправить или прояснить поведение темы «Результаты Future» в разделе «Executor, Future и CompletableFuture»?

// Фрагмент на ревью
var future = pool.submit(() -> {
    while (true) { /* interrupt не проверяется */ }
});
future.cancel(true);

Восстанавливать только ожидаемые ошибки, а неожиданные сохранять с причиной и контекстом. Настроить ThreadPoolExecutor с ограниченной очередью, политикой отклонения и метриками. Сделать флаг volatile, использовать interrupt или синхронизированный протокол остановки. Передать отдельный исполнитель задач и завершать его в finally; для ограничений времени использовать управляемые средства. Проверять прерывание и восстанавливать флаг при перехвате InterruptedException, если метод не пробрасывает его.

Вопрос 24 из 25

Почему такой асинхронный тест остаётся ненадёжным?

var f = java.util.concurrent.CompletableFuture.supplyAsync(service::load);
Thread.sleep(50);
assertTrue(f.isDone());

thenApply(this::loadAsync) создаёт CompletableFuture<CompletableFuture<Data>>. cancel(true) только запрашивает прерывание; задача остановится, если корректно реагирует на interrupt. Thread.sleep(50) не гарантирует завершение задачи: результат зависит от планировщика и нагрузки. Нужны управляемый Executor или синхронизатор. После exceptionally цепочка считается успешно восстановленной и thenApply получает запасное значение. Два потока могут прочитать одно value и записать одинаковый увеличенный результат, потеряв одно обновление.

Вопрос 25 из 25

Как точнее оценить пользу и цену решения по теме «Тестирование и диагностика» в разделе «Executor, Future и CompletableFuture»?

Композиция сохраняет неблокирующий поток данных, но длинная цепочка требует ясной политики выбора исполнителя и отмены. Исполнитель, запускающий действие прямо в новом потоке, делает цепочку детерминированной, но не обнаруживает проблемы реального параллелизма; для них нужен отдельный интеграционный сценарий. Исполнитель, запускающий действие прямо в текущем потоке, делает цепочку детерминированной, но не обнаруживает проблемы реального параллелизма; для них нужен отдельный интеграционный сценарий. Прямое управление Thread подходит для учебных и специальных задач, но пул или виртуальные потоки лучше выражают массовую работу. Единая запасная ветвь повышает доступность, но может скрыть деградацию, если не добавить метрику и ограничение области восстановления.