Диспетчеры и контексты корутин — бесплатный тест онлайн

Вопрос 1 из 25

Для «Результат withContext» предлагают правку: Обернуть только реально блокирующий или CPU-участок, не прыгать между dispatchers вокруг каждой мелкой операции. Какой компромисс нельзя пропустить?

Главный риск формулируют так: Она вернёт 100, потому что sum берёт последний элемент. Главная цена решения — необходимость учитывать, что функция вернёт Job и println покажет его состояние. Цена упрощения проявится, если вычисление продолжится после возврата compute. После внедрения придётся исходить из того, что код не компилируется: withContext разрешён только внутри launch. Локальный выбор контекста защищает вызывающего от блокировки, но библиотечный слой иногда лучше оставить нейтральным и позволить выбор владельцу.

Вопрос 2 из 25

Почему `withContext(Dispatchers.IO)` здесь уместнее одного `suspend`?

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

suspend fun legacyCall(): String = withContext(Dispatchers.IO) {
    Thread.sleep(50)
    "ok"
}

Dispatchers.IO запрещает блокирующие вызовы и бросит исключение. `Thread.sleep` блокирует поток, а `Dispatchers.IO` переносит операцию в пул для блокировок. WithContext запускает detached-корутину, которую не нужно отменять. IO преобразует Thread.sleep в delay на уровне компилятора. Опорное слово suspend само гарантирует отдельный поток, поэтому withContext лишний.

Вопрос 3 из 25

Какой принцип лежит в основе поведения «Инъекция CoroutineDispatcher»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
class Repository(private val io: CoroutineDispatcher) {
    suspend fun load() = withContext(io) { "data" }
}

Из правил языка или API следует, что чтобы строка data автоматически стала потокобезопасной. Такой результат объясняют тем, что чтобы компилятор разрешил вызвать withContext внутри suspend. Причина результата в том, что чтобы unit-тест мог не запускать корутину вообще. Инъекция dispatcher позволяет контролировать выполнение и виртуальное время, не привязывая тест к глобальным пулам. Ключевым считают контракт: Чтобы каждый Repository создавал собственный системный поток.

Вопрос 4 из 25

Какую точечную правку стоит принять на ревью фрагмента «Контекст Dispatchers.Default»?

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

fun main() = runBlocking {
    val name = withContext(Dispatchers.Default) { Thread.currentThread().name }
    println(name.isNotBlank())
}

Выбирать dispatcher по характеру работы и внедрять его в код, где тестам нужен контроль контекста. Обернуть операцию проверкой и не менять основной контракт: WithContext возвращает Job, поэтому println не компилируется. Оставить структуру прежней, документировав утверждение: Dispatchers.Default превращает блокирующий код в неблокирующий. Вынести участок в отдельный метод, считая верным следующее: Он гарантирует выполнение только на главном потоке. Оставить реализацию без изменений и закрепить тестом предположение: Он гарантирует создание нового уникального потока для каждого вызова.

Вопрос 5 из 25

Что добавить в регрессионный набор для «Замещение элемента CoroutineContext»?

Обычный ThreadLocal не следует за корутиной при смене потока; нужен `asContextElement` и понимание направления синхронизации. Отдельно проверить предположение, что будет напечатано `root`, потому что контекст нельзя переопределять у child. Проверить крайний ввод, при котором код не компилируется: coroutineContext нельзя читать внутри launch. Добавить регрессию на гипотезу: Будет напечатано `root+child`, так как имена автоматически объединяются. Считать опасной границей ситуацию, где будет напечатано `null`, потому что CoroutineName доступен только отладчику.

Вопрос 6 из 25

Почему пример «Legacy-блокировка в IO» даёт именно такой результат?

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

suspend fun legacyCall(): String = withContext(Dispatchers.IO) {
    Thread.sleep(50)
    "ok"
}

Контракт здесь понимают так: Опорное слово suspend само гарантирует отдельный поток, поэтому withContext лишний. Семантика фрагмента приводит к тому, что iO преобразует Thread.sleep в delay на уровне компилятора. Блокирующая функция занимает системный поток; suspend-модификатор без неблокирующего API этого не меняет. Объяснение опирается на утверждение: WithContext запускает detached-корутину, которую не нужно отменять. Причину поведения формулируют так: Dispatchers.IO запрещает блокирующие вызовы и бросит исключение.

Вопрос 7 из 25

Какой рефакторинг делает поведение «Инъекция CoroutineDispatcher» предсказуемее?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
class Repository(private val io: CoroutineDispatcher) {
    suspend fun load() = withContext(io) { "data" }
}

Добавить защитную проверку перед фрагментом, поскольку чтобы unit-тест мог не запускать корутину вообще. Использовать общий TestCoroutineScheduler для связанных диспетчеров и проверять завершение через `advanceUntilIdle` только там, где задача действительно отложена. Добавить локальную обработку результата, потому что чтобы каждый Repository создавал собственный системный поток. Сохранить API и считать достаточным условие: Чтобы компилятор разрешил вызвать withContext внутри suspend. Спрятать участок за вспомогательной функцией, сохранив предположение: Чтобы строка data автоматически стала потокобезопасной.

Вопрос 8 из 25

Какой сценарий выявит скрытое ограничение «Контекст Dispatchers.Default»?

Воспроизвести редкий сценарий, где он гарантирует создание нового уникального потока для каждого вызова. Отдельно проверить предположение, что withContext возвращает Job, поэтому println не компилируется. `Dispatchers.Unconfined` начинает выполнение в текущем потоке, но после приостановки продолжение может оказаться в другом месте. Добавить тест на состояние, при котором dispatchers.Default превращает блокирующий код в неблокирующий. Проверить границу полезности утверждения: Он гарантирует выполнение только на главном потоке.

Вопрос 9 из 25

Какую обратную сторону имеет решение для «Замещение элемента CoroutineContext»: Передавать диагностические идентификаторы через CoroutineName или собственный элемент контекста, не через ThreadLocal без адаптера?

Контекст удобно переносит инфраструктурные данные, но превращение его в неявный контейнер бизнес-параметров скрывает зависимости. Практическое ограничение подхода: Будет напечатано `root`, потому что контекст нельзя переопределять у child. Решение оправдано лишь при условии: Код не компилируется: coroutineContext нельзя читать внутри launch. Компромисс состоит в утверждении: Будет напечатано `root+child`, так как имена автоматически объединяются. Новый риск связан с тем, что будет напечатано `null`, потому что CoroutineName доступен только отладчику.

Вопрос 10 из 25

Какой результат вернёт `compute`?

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

suspend fun compute(): Int = withContext(Dispatchers.Default) {
    (1..100).sum()
}
fun main() = runBlocking { println(compute()) }

Код не компилируется: withContext разрешён только внутри launch. Функция вернёт `5050`: withContext дождётся блока и вернёт его последнее выражение. Функция вернёт Job и println покажет его состояние. Вычисление продолжится после возврата compute. Она вернёт 100, потому что sum берёт последний элемент.

Вопрос 11 из 25

Что добавить в регрессионный набор для «Инъекция CoroutineDispatcher»?

Проверить крайний ввод, при котором чтобы unit-тест мог не запускать корутину вообще. Считать опасной границей ситуацию, где чтобы строка data автоматически стала потокобезопасной. Проверить соседний случай: Чтобы каждый Repository создавал собственный системный поток. Подмена только Main при скрытом `Dispatchers.IO` внутри класса оставит тест зависимым от реального пула. Добавить регрессию на гипотезу: Чтобы компилятор разрешил вызвать withContext внутри suspend.

Вопрос 12 из 25

Команда собирается выбирать dispatcher по характеру работы и внедрять его в код, где тестам нужен контроль контекста. Что придётся учитывать после внедрения в «Контекст Dispatchers.Default»?

После внедрения придётся исходить из того, что withContext возвращает Job, поэтому println не компилируется. Общие диспетчеры удобны, однако скрытый выбор внутри глубокой функции осложняет тестирование и композицию. Главная цена решения — необходимость учитывать, что он гарантирует выполнение только на главном потоке. Главный риск формулируют так: Dispatchers.Default превращает блокирующий код в неблокирующий. После правки останется ограничение: Он гарантирует создание нового уникального потока для каждого вызова.

Вопрос 13 из 25

Какое имя будет напечатано?

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

fun main() = runBlocking(CoroutineName("root")) {
    launch(CoroutineName("child")) {
        println(coroutineContext[CoroutineName]?.name)
    }.join()
}

Код не компилируется: coroutineContext нельзя читать внутри launch. Будет напечатано `child`: элемент с тем же ключом в контексте дочерней корутины заменяет родительский. Будет напечатано `root`, потому что контекст нельзя переопределять у child. Будет напечатано `root+child`, так как имена автоматически объединяются. Будет напечатано `null`, потому что CoroutineName доступен только отладчику.

Вопрос 14 из 25

Какое объяснение результата «Результат withContext» выдерживает проверку соседними случаями?

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

suspend fun compute(): Int = withContext(Dispatchers.Default) {
    (1..100).sum()
}
fun main() = runBlocking { println(compute()) }

Механика примера описывается утверждением: Код не компилируется: withContext разрешён только внутри launch. Причина результата в том, что вычисление продолжится после возврата compute. `withContext` переключает контекст структурированно, не создавая отделённую задачу, и возвращает результат блока. Из правил языка или API следует, что она вернёт 100, потому что sum берёт последний элемент. Такой результат объясняют тем, что функция вернёт Job и println покажет его состояние.

Вопрос 15 из 25

Какая небольшая правка заметно повышает надёжность «Legacy-блокировка в IO»?

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

suspend fun legacyCall(): String = withContext(Dispatchers.IO) {
    Thread.sleep(50)
    "ok"
}

По возможности использовать неблокирующий клиент, а неизбежный legacy-вызов локально изолировать в IO и ограничить параллелизм. Сохранить API и считать достаточным условие: WithContext запускает detached-корутину, которую не нужно отменять. Добавить локальную обработку результата, потому что dispatchers.IO запрещает блокирующие вызовы и бросит исключение. Передать ответственность владельцу вызова, предполагая, что iO преобразует Thread.sleep в delay на уровне компилятора. Зафиксировать текущее поведение регрессионным тестом: Опорное слово suspend само гарантирует отдельный поток, поэтому withContext лишний.

Вопрос 16 из 25

Что гарантирует этот код?

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

fun main() = runBlocking {
    val name = withContext(Dispatchers.Default) { Thread.currentThread().name }
    println(name.isNotBlank())
}

Блок выполнится в контексте Default, но конкретный поток и его имя не гарантированы. WithContext возвращает Job, поэтому println не компилируется. Он гарантирует создание нового уникального потока для каждого вызова. Он гарантирует выполнение только на главном потоке. Dispatchers.Default превращает блокирующий код в неблокирующий.

Вопрос 17 из 25

Что точнее описывает механику фрагмента «Замещение элемента CoroutineContext»?

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

fun main() = runBlocking(CoroutineName("root")) {
    launch(CoroutineName("child")) {
        println(coroutineContext[CoroutineName]?.name)
    }.join()
}

Ключевым считают контракт: Будет напечатано `root+child`, так как имена автоматически объединяются. Механика примера описывается утверждением: Код не компилируется: coroutineContext нельзя читать внутри launch. Здесь действует следующее правило: Будет напечатано `root`, потому что контекст нельзя переопределять у child. Из правил языка или API следует, что будет напечатано `null`, потому что CoroutineName доступен только отладчику. CoroutineContext — набор элементов по ключам; оператор `+` объединяет их, а правый элемент с тем же ключом заменяет левый.

Вопрос 18 из 25

Что стоит исправить в «Результат withContext» перед слиянием?

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

suspend fun compute(): Int = withContext(Dispatchers.Default) {
    (1..100).sum()
}
fun main() = runBlocking { println(compute()) }

Ограничиться поясняющим комментарием о том, что она вернёт 100, потому что sum берёт последний элемент. Сохранить API и считать достаточным условие: Функция вернёт Job и println покажет его состояние. Перенести проверку в вызывающий код, исходя из того, что вычисление продолжится после возврата compute. Спрятать участок за вспомогательной функцией, сохранив предположение: Код не компилируется: withContext разрешён только внутри launch. Обернуть только реально блокирующий или CPU-участок, не прыгать между dispatchers вокруг каждой мелкой операции.

Вопрос 19 из 25

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

Неограниченное число медленных блокировок способно исчерпать соединения или внешнюю систему, даже если пул IO расширяется. Добавить регрессию на гипотезу: Dispatchers.IO запрещает блокирующие вызовы и бросит исключение. Проверить соседний случай: IO преобразует Thread.sleep в delay на уровне компилятора. Считать опасной границей ситуацию, где withContext запускает detached-корутину, которую не нужно отменять. Отдельно проверить предположение, что опорное слово suspend само гарантирует отдельный поток, поэтому withContext лишний.

Вопрос 20 из 25

Предложенная правка для «Инъекция CoroutineDispatcher» звучит так: Использовать общий TestCoroutineScheduler для связанных диспетчеров и проверять завершение через `advanceUntilIdle` только там, где задача действительно отложена. Какой недостаток важнее обсудить?

Явный dispatcher добавляет параметр инфраструктуры, зато делает конкурентный контракт наблюдаемым и тестируемым. Сопровождение усложнится, если окажется, что чтобы каждый Repository создавал собственный системный поток. Граница полезности решения описывается условием: Чтобы unit-тест мог не запускать корутину вообще. После правки останется ограничение: Чтобы компилятор разрешил вызвать withContext внутри suspend. Главная цена решения — необходимость учитывать, что чтобы строка data автоматически стала потокобезопасной.

Вопрос 21 из 25

Что следует изменить прежде всего во фрагменте «Замещение элемента CoroutineContext»?

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

fun main() = runBlocking(CoroutineName("root")) {
    launch(CoroutineName("child")) {
        println(coroutineContext[CoroutineName]?.name)
    }.join()
}

Оставить структуру прежней, документировав утверждение: Будет напечатано `root`, потому что контекст нельзя переопределять у child. Передать ответственность владельцу вызова, предполагая, что будет напечатано `root+child`, так как имена автоматически объединяются. Передавать диагностические идентификаторы через CoroutineName или собственный элемент контекста, не через ThreadLocal без адаптера. Зафиксировать текущее поведение регрессионным тестом: Будет напечатано `null`, потому что CoroutineName доступен только отладчику. Добавить локальную обработку результата, потому что код не компилируется: coroutineContext нельзя читать внутри launch.

Вопрос 22 из 25

Какой тест лучше всего защищает край контракта «Результат withContext»?

Проверить крайний ввод, при котором код не компилируется: withContext разрешён только внутри launch. Добавить регрессию на гипотезу: Она вернёт 100, потому что sum берёт последний элемент. Зафиксировать сценарий, где ожидается: Вычисление продолжится после возврата compute. Отдельно проверить предположение, что функция вернёт Job и println покажет его состояние. Переход в тот же контекст может не вызвать физической смены потока; полагаться на идентичность Thread нельзя.

Вопрос 23 из 25

Какова практическая цена решения «Legacy-блокировка в IO»: По возможности использовать неблокирующий клиент, а неизбежный legacy-вызов локально изолировать в IO и ограничить параллелизм?

Перенос защищает вычислительные потоки, но не устраняет стоимость блокировки и потребность в backpressure. Компромисс состоит в утверждении: WithContext запускает detached-корутину, которую не нужно отменять. Цена упрощения проявится, если dispatchers.IO запрещает блокирующие вызовы и бросит исключение. Главный риск формулируют так: IO преобразует Thread.sleep в delay на уровне компилятора. После внедрения придётся исходить из того, что опорное слово suspend само гарантирует отдельный поток, поэтому withContext лишний.

Вопрос 24 из 25

Зачем dispatcher передан в конструктор?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
class Repository(private val io: CoroutineDispatcher) {
    suspend fun load() = withContext(io) { "data" }
}

Чтобы unit-тест мог не запускать корутину вообще. Чтобы строка data автоматически стала потокобезопасной. Чтобы каждый Repository создавал собственный системный поток. Чтобы компилятор разрешил вызвать withContext внутри suspend. Тест подставляет управляемый `TestDispatcher`, а приложение — рабочий dispatcher.

Вопрос 25 из 25

Какой принцип лежит в основе поведения «Контекст Dispatchers.Default»?

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

fun main() = runBlocking {
    val name = withContext(Dispatchers.Default) { Thread.currentThread().name }
    println(name.isNotBlank())
}

Dispatcher определяет, где продолжать корутину, но пул может переиспользовать потоки и менять их между suspension points. Из правил языка или API следует, что он гарантирует выполнение только на главном потоке. Причина результата в том, что withContext возвращает Job, поэтому println не компилируется. Механика примера описывается утверждением: Dispatchers.Default превращает блокирующий код в неблокирующий. Такой результат объясняют тем, что он гарантирует создание нового уникального потока для каждого вызова.