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

Вопрос 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())
}

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

Вопрос 2 из 25

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

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

Вопрос 3 из 25

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

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

Вопрос 4 из 25

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

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

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

Вопрос 5 из 25

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

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

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

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

Вопрос 6 из 25

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

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

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

Вопрос 8 из 25

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

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

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

Вопрос 9 из 25

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

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

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

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

Вопрос 10 из 25

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

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

Вопрос 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)`. Объяснение опирается на утверждение: Ошибка будет проигнорирована до сборки мусора Deferred. Необработанный сбой дочерней корутины отменяет родителя и остальных детей в обычном coroutineScope. Поведение связывают с правилом: Right продолжит работу до конца, потому что async независимы. Причину поведения формулируют так: Cleanup не выполнится при отмене корутины.

Вопрос 12 из 25

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

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

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

Вопрос 13 из 25

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

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

Вопрос 14 из 25

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

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

Вопрос 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 дождался её завершения. Печатается только `done`: cancelAndJoin не меняет Job. Печатается `false`, но тело не выполняется.

Вопрос 16 из 25

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

Проверить крайний ввод, при котором проверить только, что функция имеет модификатор suspend. Отдельно проверить предположение, что запустить настоящий HTTP-запрос три раза и считать любой ответ успехом. Считать опасной границей ситуацию, где мокировать `repeat`, не управляя поведением load. `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())
}

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

Вопрос 19 из 25

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

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

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

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

Вопрос 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()
}

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

Вопрос 21 из 25

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

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

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

`delay` блокирует поток так же, как Thread.sleep, но короче записан. Функция автоматически запускается на новом потоке ввода-вывода. Функция возвращает `Deferred<Int>` вместо Int. Функция может приостановить корутину на `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, вернув список Deferred. Причину поведения формулируют так: После первой завершившейся задачи и вернёт `[2]`. Наблюдаемое поведение выводят из того, что функция не компилируется: coroutineScope нельзя возвращать значение. `coroutineScope` создаёт структурированную область, ждёт детей и отменяет соседей при необработанной ошибке одного из них. Объяснение опирается на утверждение: Только через сумму задержек, потому что async выполняются строго последовательно.

Вопрос 23 из 25

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

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

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

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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