Корутины: основы — бесплатный тест онлайн

Вопрос 1 из 25

Какой рефакторинг делает поведение «Дочерние async в coroutineScope» предсказуемее?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*

suspend fun load(): List<Int> = coroutineScope {
    val a = async { delay(20); 1 }
    val b = async { delay(10); 2 }
    listOf(a.await(), b.await())
}

Ограничиться поясняющим комментарием о том, что после первой завершившейся задачи и вернёт `[2]`. Спрятать участок за вспомогательной функцией, сохранив предположение: Только через сумму задержек, потому что async выполняются строго последовательно. Создавать дочерние задачи в scope операции, не передавая наружу Job, который переживёт владельца без явного контракта. Сохранить API и считать достаточным условие: Сразу после запуска async, вернув список Deferred. Добавить защитную проверку перед фрагментом, поскольку функция не компилируется: coroutineScope нельзя возвращать значение.

Вопрос 2 из 25

Какой тест лучше всего защищает край контракта «Отмена и ожидание Job»?

Отдельно проверить предположение, что сначала `done`, затем `false`, потому что cancel действует после delay. Считать опасной границей ситуацию, где печатается только `done`: cancelAndJoin не меняет Job. Зафиксировать сценарий, где ожидается: Печатается `false`, но тело не выполняется. Проверить крайний ввод, при котором код зависает, так как join нельзя вызывать после cancel. CPU-цикл без suspension/check (`yield`, `ensureActive`, `isActive`) может не заметить отмену своевременно.

Вопрос 3 из 25

Команда собирается использовать supervisor только когда частичная независимость является предметным требованием и ошибки каждого ребёнка обрабатываются отдельно. Что придётся учитывать после внедрения в «Сбой одного ребёнка»?

После внедрения придётся исходить из того, что ошибка будет проигнорирована до сборки мусора Deferred. После правки останется ограничение: Right продолжит работу до конца, потому что async независимы. Fail-fast предотвращает работу с неполным результатом, но агрегирующим операциям иногда нужен контролируемый сбор частичных ошибок. Главная цена решения — необходимость учитывать, что ошибка превратится в ноль и функция вернёт `(0, 2)`. Главный риск формулируют так: Cleanup не выполнится при отмене корутины.

Вопрос 4 из 25

Как тестировать такую функцию без реальных задержек и сети?

// Проследите фактическое выполнение без изменения кода.
suspend fun retry(load: suspend () -> String): String {
    repeat(2) { runCatching { return load() } }
    return load()
}

Проверить только, что функция имеет модификатор suspend. Добавить Thread.sleep между вызовами, хотя функция задержек не содержит. Запустить настоящий HTTP-запрос три раза и считать любой ответ успехом. Передать fake-лямбду с заданной последовательностью ошибок и успеха, затем проверить число вызовов и итог. Мокировать `repeat`, не управляя поведением load.

Вопрос 5 из 25

Какое утверждение точнее всего объясняет поведение фрагмента «Приостановка без нового потока»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*

suspend fun answer(): Int { delay(10); return 42 }
fun main() = runBlocking { println(answer()) }

Наблюдаемое поведение выводят из того, что `delay` блокирует поток так же, как Thread.sleep, но короче записан. Объяснение опирается на утверждение: Опорное слово запрещает выполнять код между точками приостановки. Контракт здесь понимают так: Функция автоматически запускается на новом потоке ввода-вывода. Причину поведения формулируют так: Функция возвращает `Deferred<Int>` вместо Int. `suspend` меняет протокол вызова и разрешает точки приостановки; оно не выбирает dispatcher и не создаёт корутину само.

Вопрос 6 из 25

Что может усложниться в сопровождении после изменения «Отмена и ожидание Job»: Хранить Job только там, где владелец обязан отменять конкретную операцию, и предпочитать отмену родительского scope для группы работ?

Решение оправдано лишь при условии: Печатается только `done`: cancelAndJoin не меняет Job. Обратная сторона изменения состоит в том, что код зависает, так как join нельзя вызывать после cancel. Явный Job даёт точечный контроль, но множество независимых Job легко разрывает структурированную конкурентность. Сопровождение усложнится, если окажется, что печатается `false`, но тело не выполняется. Новый риск связан с тем, что сначала `done`, затем `false`, потому что cancel действует после delay.

Вопрос 7 из 25

Что произойдёт после ошибки `left`?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*

suspend fun pair(): Pair<Int, Int> = coroutineScope {
    val left = async { delay(10); error("boom") }
    val right = async { try { delay(1000); 2 } finally { println("cleanup") } }
    left.await() to right.await()
}

Ошибка будет проигнорирована до сборки мусора Deferred. Cleanup не выполнится при отмене корутины. Scope завершится ошибкой, `right` будет отменён, а его `finally` выполнит cleanup. Ошибка превратится в ноль и функция вернёт `(0, 2)`. Right продолжит работу до конца, потому что async независимы.

Вопрос 8 из 25

Какой принцип лежит в основе поведения «Детерминированный тест suspend-функции»?

// На ревью требуется объяснить причину поведения.
suspend fun retry(load: suspend () -> String): String {
    repeat(2) { runCatching { return load() } }
    return load()
}

Такой результат объясняют тем, что добавить Thread.sleep между вызовами, хотя функция задержек не содержит. Ключевым считают контракт: Запустить настоящий HTTP-запрос три раза и считать любой ответ успехом. Механика примера описывается утверждением: Мокировать `repeat`, не управляя поведением load. Suspend-код тестируется детерминированно через внедрённые зависимости и `runTest`; виртуальное время нужно только для операторов времени. Причина результата в том, что проверить только, что функция имеет модификатор suspend.

Вопрос 9 из 25

Какую правку выбрать, чтобы сохранить назначение «Приостановка без нового потока» и убрать хрупкость?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*

suspend fun answer(): Int { delay(10); return 42 }
fun main() = runBlocking { println(answer()) }

Зафиксировать текущее поведение регрессионным тестом: `delay` блокирует поток так же, как Thread.sleep, но короче записан. Вынести участок в отдельный метод, считая верным следующее: Функция автоматически запускается на новом потоке ввода-вывода. Вызывать suspend-операции из управляемого scope и не скрывать блокирующий ввод-вывод под одним лишь опорным словом. Обернуть операцию проверкой и не менять основной контракт: Опорное слово запрещает выполнять код между точками приостановки. Оставить структуру прежней, документировав утверждение: Функция возвращает `Deferred<Int>` вместо Int.

Вопрос 10 из 25

Где упрощённое объяснение «Дочерние async в coroutineScope» перестаёт работать?

Проверить границу полезности утверждения: Функция не компилируется: coroutineScope нельзя возвращать значение. Добавить граничный тест на утверждение: Сразу после запуска async, вернув список Deferred. Отдельно воспроизвести случай, в котором после первой завершившейся задачи и вернёт `[2]`. Воспроизвести редкий сценарий, где только через сумму задержек, потому что async выполняются строго последовательно. `supervisorScope` меняет распространение сбоя между детьми, но всё равно ждёт завершения всех дочерних задач.

Вопрос 11 из 25

Почему пример «Сбой одного ребёнка» даёт именно такой результат?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*

suspend fun pair(): Pair<Int, Int> = coroutineScope {
    val left = async { delay(10); error("boom") }
    val right = async { try { delay(1000); 2 } finally { println("cleanup") } }
    left.await() to right.await()
}

Контракт здесь понимают так: Ошибка превратится в ноль и функция вернёт `(0, 2)`. Поведение связывают с правилом: Right продолжит работу до конца, потому что async независимы. Необработанный сбой дочерней корутины отменяет родителя и остальных детей в обычном coroutineScope. Объяснение опирается на утверждение: Ошибка будет проигнорирована до сборки мусора Deferred. Причину поведения формулируют так: Cleanup не выполнится при отмене корутины.

Вопрос 12 из 25

Какая небольшая правка заметно повышает надёжность «Детерминированный тест suspend-функции»?

// Сохраните назначение фрагмента, но укрепите его контракт.
suspend fun retry(load: suspend () -> String): String {
    repeat(2) { runCatching { return load() } }
    return load()
}

Сохранить API и считать достаточным условие: Проверить только, что функция имеет модификатор suspend. Сделать политику повторов отдельной зависимостью, не ловить CancellationException и добавить сценарии успеха с первой/второй попытки и полного отказа. Обернуть операцию проверкой и не менять основной контракт: Запустить настоящий HTTP-запрос три раза и считать любой ответ успехом. Добавить локальную обработку результата, потому что мокировать `repeat`, не управляя поведением load. Зафиксировать текущее поведение регрессионным тестом: Добавить Thread.sleep между вызовами, хотя функция задержек не содержит.

Вопрос 13 из 25

Где упрощённое объяснение «Приостановка без нового потока» перестаёт работать?

Добавить граничный тест на утверждение: Функция автоматически запускается на новом потоке ввода-вывода. Отдельно воспроизвести случай, в котором функция возвращает `Deferred<Int>` вместо Int. Проверить границу полезности утверждения: Опорное слово запрещает выполнять код между точками приостановки. Добавить тест на состояние, при котором `delay` блокирует поток так же, как Thread.sleep, но короче записан. Suspend-функция может долго вычислять без единой точки отмены и занять поток, несмотря на пометку `suspend`.

Вопрос 14 из 25

Для «Дочерние async в coroutineScope» предлагают правку: Создавать дочерние задачи в scope операции, не передавая наружу Job, который переживёт владельца без явного контракта. Какой компромисс нельзя пропустить?

Главный риск формулируют так: Только через сумму задержек, потому что async выполняются строго последовательно. Граница полезности решения описывается условием: После первой завершившейся задачи и вернёт `[2]`. Структура делает жизненный цикл предсказуемым, хотя иногда требует явно выделить более долгоживущий application scope. Цена упрощения проявится, если функция не компилируется: coroutineScope нельзя возвращать значение. Главная цена решения — необходимость учитывать, что сразу после запуска async, вернув список Deferred.

Вопрос 15 из 25

Какие строки ожидаются?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch { delay(100); println("done") }
    job.cancelAndJoin()
    println(job.isCancelled)
}

Код зависает, так как join нельзя вызывать после cancel. Сначала `done`, затем `false`, потому что cancel действует после delay. `done` не печатается, затем печатается `true`: задача отменена и join дождался её завершения. Печатается `false`, но тело не выполняется. Печатается только `done`: cancelAndJoin не меняет Job.

Вопрос 16 из 25

Что добавить в регрессионный набор для «Детерминированный тест suspend-функции»?

Считать опасной границей ситуацию, где мокировать `repeat`, не управляя поведением load. Отдельно проверить предположение, что запустить настоящий HTTP-запрос три раза и считать любой ответ успехом. Проверить крайний ввод, при котором проверить только, что функция имеет модификатор suspend. `runCatching` в текущем виде может перехватить CancellationException; тест отмены обязан обнаружить это нарушение. Добавить регрессию на гипотезу: Добавить Thread.sleep между вызовами, хотя функция задержек не содержит.

Вопрос 17 из 25

Для «Приостановка без нового потока» предлагают правку: Вызывать suspend-операции из управляемого scope и не скрывать блокирующий ввод-вывод под одним лишь опорным словом. Какой компромисс нельзя пропустить?

Последовательный suspend-код читается как обычный, но требует осознанного управления scope, контекстом и отменой. Цена упрощения проявится, если `delay` блокирует поток так же, как Thread.sleep, но короче записан. Главный риск формулируют так: Функция возвращает `Deferred<Int>` вместо Int. Главная цена решения — необходимость учитывать, что функция автоматически запускается на новом потоке ввода-вывода. После внедрения придётся исходить из того, что опорное слово запрещает выполнять код между точками приостановки.

Вопрос 18 из 25

Когда завершится `load`?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*

suspend fun load(): List<Int> = coroutineScope {
    val a = async { delay(20); 1 }
    val b = async { delay(10); 2 }
    listOf(a.await(), b.await())
}

Сразу после запуска async, вернув список Deferred. Только после завершения обоих дочерних async; результат сохранит порядок await и будет `[1, 2]`. После первой завершившейся задачи и вернёт `[2]`. Только через сумму задержек, потому что async выполняются строго последовательно. Функция не компилируется: coroutineScope нельзя возвращать значение.

Вопрос 19 из 25

Какое утверждение точнее всего объясняет поведение фрагмента «Отмена и ожидание Job»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch { delay(100); println("done") }
    job.cancelAndJoin()
    println(job.isCancelled)
}

Здесь действует следующее правило: Печатается `false`, но тело не выполняется. Контракт здесь понимают так: Сначала `done`, затем `false`, потому что cancel действует после delay. Объяснение опирается на утверждение: Код зависает, так как join нельзя вызывать после cancel. Причину поведения формулируют так: Печатается только `done`: cancelAndJoin не меняет Job. Job представляет жизненный цикл корутины; отмена кооперативна, а `join` ждёт окончательного завершения.

Вопрос 20 из 25

Какая небольшая правка заметно повышает надёжность «Сбой одного ребёнка»?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*

suspend fun pair(): Pair<Int, Int> = coroutineScope {
    val left = async { delay(10); error("boom") }
    val right = async { try { delay(1000); 2 } finally { println("cleanup") } }
    left.await() to right.await()
}

Добавить локальную обработку результата, потому что ошибка будет проигнорирована до сборки мусора Deferred. Передать ответственность владельцу вызова, предполагая, что ошибка превратится в ноль и функция вернёт `(0, 2)`. Использовать supervisor только когда частичная независимость является предметным требованием и ошибки каждого ребёнка обрабатываются отдельно. Зафиксировать текущее поведение регрессионным тестом: Cleanup не выполнится при отмене корутины. Обернуть операцию проверкой и не менять основной контракт: Right продолжит работу до конца, потому что async независимы.

Вопрос 21 из 25

Что означает `suspend` в этом примере?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*

suspend fun answer(): Int { delay(10); return 42 }
fun main() = runBlocking { println(answer()) }

Опорное слово запрещает выполнять код между точками приостановки. Функция возвращает `Deferred<Int>` вместо Int. `delay` блокирует поток так же, как Thread.sleep, но короче записан. Функция может приостановить корутину на `delay` без блокировки её потока и затем вернуть 42. Функция автоматически запускается на новом потоке ввода-вывода.

Вопрос 22 из 25

На какой контракт языка или библиотеки опирается «Дочерние async в coroutineScope»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*

suspend fun load(): List<Int> = coroutineScope {
    val a = async { delay(20); 1 }
    val b = async { delay(10); 2 }
    listOf(a.await(), b.await())
}

Объяснение опирается на утверждение: Только через сумму задержек, потому что async выполняются строго последовательно. `coroutineScope` создаёт структурированную область, ждёт детей и отменяет соседей при необработанной ошибке одного из них. Причину поведения формулируют так: После первой завершившейся задачи и вернёт `[2]`. Наблюдаемое поведение выводят из того, что функция не компилируется: coroutineScope нельзя возвращать значение. Поведение связывают с правилом: Сразу после запуска async, вернув список Deferred.

Вопрос 23 из 25

Как укрепить «Отмена и ожидание Job», не переписывая соседние модули?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch { delay(100); println("done") }
    job.cancelAndJoin()
    println(job.isCancelled)
}

Перенести проверку в вызывающий код, исходя из того, что печатается только `done`: cancelAndJoin не меняет Job. Добавить защитную проверку перед фрагментом, поскольку сначала `done`, затем `false`, потому что cancel действует после delay. Вынести участок в отдельный метод, считая верным следующее: Код зависает, так как join нельзя вызывать после cancel. Хранить Job только там, где владелец обязан отменять конкретную операцию, и предпочитать отмену родительского scope для группы работ. Оставить структуру прежней, документировав утверждение: Печатается `false`, но тело не выполняется.

Вопрос 24 из 25

Что добавить в регрессионный набор для «Сбой одного ребёнка»?

Исключение async наблюдается через await, но его связь с родителем всё равно может отменить scope до конкретного await. Добавить регрессию на гипотезу: Cleanup не выполнится при отмене корутины. Проверить соседний случай: Right продолжит работу до конца, потому что async независимы. Проверить крайний ввод, при котором ошибка будет проигнорирована до сборки мусора Deferred. Отдельно проверить предположение, что ошибка превратится в ноль и функция вернёт `(0, 2)`.

Вопрос 25 из 25

Предложенная правка для «Детерминированный тест suspend-функции» звучит так: Сделать политику повторов отдельной зависимостью, не ловить CancellationException и добавить сценарии успеха с первой/второй попытки и полного отказа. Какой недостаток важнее обсудить?

Главная цена решения — необходимость учитывать, что проверить только, что функция имеет модификатор suspend. После правки останется ограничение: Мокировать `repeat`, не управляя поведением load. Fake проще и стабильнее тяжёлого mock-фреймворка, но интеграционный тест всё равно нужен для реального клиента и протокола. Обратная сторона изменения состоит в том, что запустить настоящий HTTP-запрос три раза и считать любой ответ успехом. Сопровождение усложнится, если окажется, что добавить Thread.sleep между вызовами, хотя функция задержек не содержит.