Каналы — бесплатный тест онлайн

Вопрос 1 из 25

Чем завершится выполнение «Получение до закрытия Channel»?

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

fun main() = runBlocking {
    val ch = Channel<Int>()
    launch { ch.send(1); ch.send(2); ch.close() }
    for (x in ch) print(x)
}

Она напечатает `21`, так как send не сохраняет порядок. Код не компилируется: send разрешён только producer builder. Она напечатает `12`: цикл получает значения до закрытия канала и затем завершается. Цикл зависнет после второго значения, поскольку close не виден получателю. Она напечатает только `1`, потому что Channel одноэлементный.

Вопрос 2 из 25

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

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

fun main() = runBlocking {
    val ch = Channel<Int>(capacity = 1)
    ch.send(1)
    println("sent")
    println(ch.receive())
    ch.close()
}

Ёмкость и политика переполнения определяют, когда send приостанавливается и какие значения могут быть потеряны. Здесь действует следующее правило: Send в показанном сценарии неблокирующий независимо от capacity. Такой результат объясняют тем, что значение не помещается в канал, а хранится в локальной переменной компилятора. Из правил языка или API следует, что capacity=1 означает одного производителя, а не один элемент. Ключевым считают контракт: Channel создаёт скрытый consumer при первом send.

Вопрос 3 из 25

Как превратить неявное предположение в проверяемый контракт «Ожидание первого канала»?

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

suspend fun first(a: ReceiveChannel<Int>, b: ReceiveChannel<Int>) = select<Int> {
    a.onReceive { it }
    b.onReceive { it }
}

Документировать политику при одновременной готовности и обрабатывать закрытие через подходящие clause, а не считать его обычным значением. Сохранить API и считать достаточным условие: Она получает по одному значению из обоих каналов и возвращает сумму. Зафиксировать текущее поведение регрессионным тестом: Она в показанном сценарии читает `a`, даже если готов только b. Ограничиться поясняющим комментарием о том, что она запускает два системных потока и отменяет более медленный. Спрятать участок за вспомогательной функцией, сохранив предположение: Она возвращает null, если оба канала пока пусты.

Вопрос 4 из 25

Какой соседний случай отличает устойчивое решение «Автоматическое закрытие produce» от удачного примера?

Считать опасной границей ситуацию, где код не компилируется: produce не может быть extension CoroutineScope. Проверить соседний случай: Будет напечатано только `0`, потому что produce закрывается после первого send. Добавить тест на состояние, при котором канал останется открыт, и consumeEach зависнет нав показанном сценарии. Добавить регрессию на гипотезу: Finally не выполняется при нормальном завершении producer. Ранний выход потребителя без `consume`/cancel может оставить производителя приостановленным на send и удерживать ресурсы.

Вопрос 5 из 25

Предложенная правка для «Тест завершения consumer» звучит так: Использовать ограниченный test scope, явно закрывать producer и после проверки убеждаться, что дочерние корутины завершены. Какой недостаток важнее обсудить?

Граница полезности решения описывается условием: Запустить drain в GlobalScope и завершить тест сразу после send. Сопровождение усложнится, если окажется, что проверить только `isClosedForReceive` до запуска drain. После правки останется ограничение: Мокировать iterator канала обычным List, не проверяя suspension и закрытие. Реальный Channel лучше fake-очереди проверяет suspension, но тесту нужны строгие границы времени и жизненного цикла. Обратная сторона изменения состоит в том, что отправить одно значение и не закрывать канал, ожидая возврата drain.

Вопрос 6 из 25

Какое изменение лучше всего защищает границу «Первое значение в буфере»?

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

fun main() = runBlocking {
    val ch = Channel<Int>(capacity = 1)
    ch.send(1)
    println("sent")
    println(ch.receive())
    ch.close()
}

Добавить локальную обработку результата, потому что значение не помещается в канал, а хранится в локальной переменной компилятора. Передать ответственность владельцу вызова, предполагая, что send в показанном сценарии неблокирующий независимо от capacity. Сохранить API и считать достаточным условие: Capacity=1 означает одного производителя, а не один элемент. Зафиксировать текущее поведение регрессионным тестом: Channel создаёт скрытый consumer при первом send. Выбирать размер из модели нагрузки и измерений; не использовать огромный буфер как замену backpressure.

Вопрос 7 из 25

На каком входе или состоянии граница «Ожидание первого канала» становится заметной?

Считать опасной границей ситуацию, где она в показанном сценарии читает `a`, даже если готов только b. Зафиксировать сценарий, где ожидается: Она запускает два системных потока и отменяет более медленный. Проверить крайний ввод, при котором она получает по одному значению из обоих каналов и возвращает сумму. При постоянной готовности первой clause возможна несправедливость; unbiased-выбор или иной дизайн нужен, если это важно. Проверить, сохраняется ли контракт, когда она возвращает null, если оба канала пока пусты.

Вопрос 8 из 25

Какое ограничение сохранится после правки «Автоматическое закрытие produce»: Не закрывать канал со стороны нескольких потребителей и обеспечить отмену producer, когда результат больше никому не нужен?

Решение оправдано лишь при условии: Код не компилируется: produce не может быть extension CoroutineScope. Цена упрощения проявится, если канал останется открыт, и consumeEach зависнет нав показанном сценарии. Компромисс состоит в утверждении: Будет напечатано только `0`, потому что produce закрывается после первого send. Новый риск связан с тем, что finally не выполняется при нормальном завершении producer. Явный протокол завершения делает очередь надёжной, но требует единственного владельца закрытия и обработки причины.

Вопрос 9 из 25

Какой тест проверяет и данные, и завершение?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.channels.*
suspend fun drain(ch: ReceiveChannel<Int>): Int {
    var sum = 0
    for (x in ch) sum += x
    return sum
}

Мокировать iterator канала обычным List, не проверяя suspension и закрытие. Отправить одно значение и не закрывать канал, ожидая возврата drain. Проверить только `isClosedForReceive` до запуска drain. В `runTest` отправить 1, 2, 3, закрыть канал, вызвать drain и проверить сумму 6. Запустить drain в GlobalScope и завершить тест сразу после send.

Вопрос 10 из 25

Почему пример «Получение до закрытия Channel» даёт именно такой результат?

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

fun main() = runBlocking {
    val ch = Channel<Int>()
    launch { ch.send(1); ch.send(2); ch.close() }
    for (x in ch) print(x)
}

Channel передаёт значения между корутинами; закрытие сообщает, что новых значений не будет, но уже отправленные остаются доступны. Объяснение опирается на утверждение: Она напечатает `21`, так как send не сохраняет порядок. Поведение связывают с правилом: Цикл зависнет после второго значения, поскольку close не виден получателю. Семантика фрагмента приводит к тому, что она напечатает только `1`, потому что Channel одноэлементный. Контракт здесь понимают так: Код не компилируется: send разрешён только producer builder.

Вопрос 11 из 25

Какое ограничение сохранится после правки «Ожидание первого канала»: Документировать политику при одновременной готовности и обрабатывать закрытие через подходящие clause, а не считать его обычным значением?

Новый риск связан с тем, что она возвращает null, если оба канала пока пусты. Select выражает гонку источников без ручных jobs, но усложняет доказательство справедливости, закрытия и отмены. Цена упрощения проявится, если она в показанном сценарии читает `a`, даже если готов только b. Практическое ограничение подхода: Она получает по одному значению из обоих каналов и возвращает сумму. Компромисс состоит в утверждении: Она запускает два системных потока и отменяет более медленный.

Вопрос 12 из 25

Что произойдёт после трёх значений?

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

@OptIn(ExperimentalCoroutinesApi::class)
fun CoroutineScope.values() = produce<Int> {
    try { repeat(3) { send(it) } }
    finally { println("producer closed") }
}
fun main() = runBlocking {
    values().consumeEach { print(it) }
}

Finally не выполняется при нормальном завершении producer. Канал останется открыт, и consumeEach зависнет нав показанном сценарии. Будет напечатано только `0`, потому что produce закрывается после первого send. Код не компилируется: produce не может быть extension CoroutineScope. Будет `012`, затем сообщение из `finally`: `produce` закроет канал после завершения тела.

Вопрос 13 из 25

Что в семантике Kotlin или используемого API объясняет «Тест завершения consumer»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.channels.*
suspend fun drain(ch: ReceiveChannel<Int>): Int {
    var sum = 0
    for (x in ch) sum += x
    return sum
}

Механика примера описывается утверждением: Отправить одно значение и не закрывать канал, ожидая возврата drain. Поведение связывают с правилом: Мокировать iterator канала обычным List, не проверяя suspension и закрытие. Семантика фрагмента приводит к тому, что проверить только `isClosedForReceive` до запуска drain. Контракт здесь понимают так: Запустить drain в GlobalScope и завершить тест сразу после send. Тест протокола канала обязан управлять закрытием и Job, иначе зависание или утечка может быть случайно скрыта тестовым раннером.

Вопрос 14 из 25

Что изменить в «Получение до закрытия Channel», чтобы скрытое допущение стало явным контрактом?

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

fun main() = runBlocking {
    val ch = Channel<Int>()
    launch { ch.send(1); ch.send(2); ch.close() }
    for (x in ch) print(x)
}

Оставить структуру прежней, документировав утверждение: Код не компилируется: send разрешён только producer builder. Закрывать канал на стороне производителя и предпочитать `produce`/`channelFlow`, когда жизненный цикл можно связать со scope. Перенести проверку в вызывающий код, исходя из того, что она напечатает только `1`, потому что Channel одноэлементный. Обернуть операцию проверкой и не менять основной контракт: Она напечатает `21`, так как send не сохраняет порядок. Оставить реализацию без изменений и закрепить тестом предположение: Цикл зависнет после второго значения, поскольку close не виден получателю.

Вопрос 15 из 25

Какой редкий случай способен сломать наивную трактовку «Первое значение в буфере»?

Воспроизвести редкий сценарий, где capacity=1 означает одного производителя, а не один элемент. Проверить, сохраняется ли контракт, когда channel создаёт скрытый consumer при первом send. Добавить граничный тест на утверждение: Значение не помещается в канал, а хранится в локальной переменной компилятора. `Channel.CONFLATED` сохраняет только последнее значение и не подходит для событий, каждое из которых обязано быть обработано. Зафиксировать сценарий, где ожидается: Send в показанном сценарии неблокирующий независимо от capacity.

Вопрос 16 из 25

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

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

@OptIn(ExperimentalCoroutinesApi::class)
fun CoroutineScope.values() = produce<Int> {
    try { repeat(3) { send(it) } }
    finally { println("producer closed") }
}
fun main() = runBlocking {
    values().consumeEach { print(it) }
}

Наблюдаемое поведение выводят из того, что канал останется открыт, и consumeEach зависнет нав показанном сценарии. Ключевым считают контракт: Finally не выполняется при нормальном завершении producer. Производитель должен владеть закрытием своего выходного канала; structured builder связывает его отмену и завершение со scope. Такой результат объясняют тем, что код не компилируется: produce не может быть extension CoroutineScope. Здесь действует следующее правило: Будет напечатано только `0`, потому что produce закрывается после первого send.

Вопрос 17 из 25

Какая правка устраняет причину риска в «Тест завершения consumer», а не только его проявление?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.channels.*
suspend fun drain(ch: ReceiveChannel<Int>): Int {
    var sum = 0
    for (x in ch) sum += x
    return sum
}

Добавить защитную проверку перед фрагментом, поскольку отправить одно значение и не закрывать канал, ожидая возврата drain. Использовать ограниченный test scope, явно закрывать producer и после проверки убеждаться, что дочерние корутины завершены. Вынести участок в отдельный метод, считая верным следующее: Запустить drain в GlobalScope и завершить тест сразу после send. Перенести проверку в вызывающий код, исходя из того, что проверить только `isClosedForReceive` до запуска drain. Оставить реализацию без изменений и закрепить тестом предположение: Мокировать iterator канала обычным List, не проверяя suspension и закрытие.

Вопрос 18 из 25

Какой пограничный сценарий обязательно добавить к проверкам «Получение до закрытия Channel»?

Проверить соседний случай: Она напечатает `21`, так как send не сохраняет порядок. Закрытие с причиной делает получение после буфера ошибочным; отмена consumer не обязана автоматически закрыть произвольного producer-владельца. Проверить границу полезности утверждения: Цикл зависнет после второго значения, поскольку close не виден получателю. Отдельно воспроизвести случай, в котором она напечатает только `1`, потому что Channel одноэлементный. Добавить тест на состояние, при котором код не компилируется: send разрешён только producer builder.

Вопрос 19 из 25

В «Первое значение в буфере» выбрали решение: Выбирать размер из модели нагрузки и измерений; не использовать огромный буфер как замену backpressure. Какова его реальная цена?

После правки останется ограничение: Channel создаёт скрытый consumer при первом send. Главный риск формулируют так: Capacity=1 означает одного производителя, а не один элемент. Сопровождение усложнится, если окажется, что send в показанном сценарии неблокирующий независимо от capacity. Буфер сглаживает краткие всплески и развязывает скорости, но увеличивает задержку, память и объём работы после устаревания данных. Граница полезности решения описывается условием: Значение не помещается в канал, а хранится в локальной переменной компилятора.

Вопрос 20 из 25

Какой контракт у функции `first`?

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

suspend fun first(a: ReceiveChannel<Int>, b: ReceiveChannel<Int>) = select<Int> {
    a.onReceive { it }
    b.onReceive { it }
}

Она запускает два системных потока и отменяет более медленный. Она ждёт готовности одного канала и возвращает значение выбранной ветви `select`. Она возвращает null, если оба канала пока пусты. Она в показанном сценарии читает `a`, даже если готов только b. Она получает по одному значению из обоих каналов и возвращает сумму.

Вопрос 21 из 25

Какой дополнительный сценарий нужен для «Тест завершения consumer»?

Буфер может позволить тесту пройти, даже если consumer запускается слишком поздно; rendezvous-сценарий отдельно проверяет синхронизацию. Зафиксировать сценарий, где ожидается: Мокировать iterator канала обычным List, не проверяя suspension и закрытие. Проверить крайний ввод, при котором проверить только `isClosedForReceive` до запуска drain. Считать опасной границей ситуацию, где отправить одно значение и не закрывать канал, ожидая возврата drain. Проверить, сохраняется ли контракт, когда запустить drain в GlobalScope и завершить тест сразу после send.

Вопрос 22 из 25

В «Получение до закрытия Channel» выбрали решение: Закрывать канал на стороне производителя и предпочитать `produce`/`channelFlow`, когда жизненный цикл можно связать со scope. Какова его реальная цена?

Граница полезности решения описывается условием: Код не компилируется: send разрешён только producer builder. После правки останется ограничение: Она напечатает только `1`, потому что Channel одноэлементный. Channel подходит для очереди работ и rendezvous, но для широковещательного состояния чаще лучше StateFlow/SharedFlow. Главный риск формулируют так: Она напечатает `21`, так как send не сохраняет порядок. Главная цена решения — необходимость учитывать, что цикл зависнет после второго значения, поскольку close не виден получателю.

Вопрос 23 из 25

Почему `sent` появляется до receive?

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

fun main() = runBlocking {
    val ch = Channel<Int>(capacity = 1)
    ch.send(1)
    println("sent")
    println(ch.receive())
    ch.close()
}

Capacity=1 означает одного производителя, а не один элемент. Буфер ёмкости 1 принимает первое значение без ожидающего получателя; затем receive извлекает 1. Значение не помещается в канал, а хранится в локальной переменной компилятора. Send в показанном сценарии неблокирующий независимо от capacity. Channel создаёт скрытый consumer при первом send.

Вопрос 24 из 25

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

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

suspend fun first(a: ReceiveChannel<Int>, b: ReceiveChannel<Int>) = select<Int> {
    a.onReceive { it }
    b.onReceive { it }
}

Поведение связывают с правилом: Она получает по одному значению из обоих каналов и возвращает сумму. Объяснение опирается на утверждение: Она возвращает null, если оба канала пока пусты. Причину поведения формулируют так: Она запускает два системных потока и отменяет более медленный. `select` ожидает одну из нескольких suspend-операций и атомарно выбирает готовую clause в рамках поддерживаемого протокола. Семантика фрагмента приводит к тому, что она в показанном сценарии читает `a`, даже если готов только b.

Вопрос 25 из 25

Как сделать ответственность во фрагменте «Автоматическое закрытие produce» понятной следующему разработчику?

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

@OptIn(ExperimentalCoroutinesApi::class)
fun CoroutineScope.values() = produce<Int> {
    try { repeat(3) { send(it) } }
    finally { println("producer closed") }
}
fun main() = runBlocking {
    values().consumeEach { print(it) }
}

Не закрывать канал со стороны нескольких потребителей и обеспечить отмену producer, когда результат больше никому не нужен. Оставить реализацию без изменений и закрепить тестом предположение: Код не компилируется: produce не может быть extension CoroutineScope. Спрятать участок за вспомогательной функцией, сохранив предположение: Будет напечатано только `0`, потому что produce закрывается после первого send. Ограничиться поясняющим комментарием о том, что канал останется открыт, и consumeEach зависнет нав показанном сценарии. Добавить защитную проверку перед фрагментом, поскольку finally не выполняется при нормальном завершении producer.