💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В каждом задании верен только один вариант. Фрагменты относятся к Scala 3; внешняя библиотека названа прямо в коде или условии.
Вопрос 21 из 30
Во фрагменте проверяется тема «Разбор отказов». Какое правило точнее всего объясняет поведение кода?
Scala Разбор отказов: чтение фрагмента Копировать
case class PoolSnapshot(activeFibers: Int, waitingPermits: Int, queued: Int, openConnections: Int)
val before = PoolSnapshot(40, 0, 2, 18)
val during = PoolSnapshot(400, 280, 900, 20)
val starvationLikely =
during.waitingPermits > before.waitingPermits &&
during.openConnections <= before.openConnections + 2
println(starvationLikely)
Гонка эффектов возвращает победителя, но проигравший всегда продолжает работу в фоне до естественного завершения.
Разбор отказа требует отличить взаимную блокировку, голодание потоков, исчерпанный пул, утечку ресурсов и медленную работу зависимого сервиса.
Значение `IO` выполняет эффект в момент построения, а `unsafeRun*` лишь извлекает уже сохранённый результат.
Восстановление системы после конкурентного сбоя должно учитывать незавершённые операции и повторный запуск.
Волокно — лёгкое управляемое вычисление эффекта; его жизненный цикл должен быть связан с родительской областью.
Вопрос 22 из 30
Для темы «Разбор отказов» на какой границе это решение перестаёт быть достаточным?
Scala Разбор отказов: изменившийся контекст Копировать
// Дополнительный контекст: Дочернее волокно продолжило работу после выхода из родительской области.
case class PoolSnapshot(activeFibers: Int, waitingPermits: Int, queued: Int, openConnections: Int)
val before = PoolSnapshot(40, 0, 2, 18)
val during = PoolSnapshot(400, 280, 900, 20)
val starvationLikely =
during.waitingPermits > before.waitingPermits &&
during.openConnections <= before.openConnections + 2
println(starvationLikely)
Отсоединённое волокно продолжает держать соединение или писать данные после отмены запроса.
Финализатор, который сам зависает или падает, может затянуть shutdown и скрыть исходную ошибку.
Реальное ожидание в тесте надёжнее управляемых часов: оно точнее воспроизводит планировщик рабочей системы.
Увеличение числа потоков без диагноза может усилить contention и отложить исчерпание памяти.
`Resource` защищает только от утечки памяти; файловые дескрипторы и соединения от его финализатора не зависят.
Вопрос 23 из 30
При исправлении темы «Разбор отказов» что следует изменить, чтобы следующий рефакторинг не вернул тот же риск?
Scala Разбор отказов: решение на ревью Копировать
case class PoolSnapshot(activeFibers: Int, waitingPermits: Int, queued: Int, openConnections: Int)
val before = PoolSnapshot(40, 0, 2, 18)
val during = PoolSnapshot(400, 280, 900, 20)
val starvationLikely =
during.waitingPermits > before.waitingPermits &&
during.openConnections <= before.openConnections + 2
println(starvationLikely)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Делайте release идемпотентным, ограниченным по времени и логируйте обе причины при двойной ошибке.
После тайм-аута сразу повторять внешний эффект без ключа идемпотентности и без проверки судьбы первой попытки.
Свяжите лимит с реальной ёмкостью зависимого сервиса и измеряйте ожидание разрешения семафора отдельно от времени операции.
Соберите thread dump, метрики очередей, разрешений семафора и открытых ресурсов; изменяйте один лимит после подтверждения причины.
Сводить все ошибки к одной строке и продолжать вычисление, не сохраняя исходную причину и этап программы.
Вопрос 24 из 30
В контракте темы «Разбор отказов» что следует оставить в проектном решении после этого изменения контекста?
Опираться на семантику «разбор отказа требует отличить взаимную блокировку, голодание потоков, исчерпанный пул, утечку ресурсов и медленную работу зависимого сервиса», но отдельно проверять ограничение «увеличение числа потоков без диагноза может усилить contention и отложить исчерпание памяти».
Опираться на семантику «разбор отказа требует отличить взаимную блокировку, голодание потоков, исчерпанный пул, утечку ресурсов и медленную работу зависимого сервиса», но отдельно проверять ограничение «отсоединённое волокно продолжает держать соединение или писать данные после отмены запроса».
Опираться на семантику «разбор отказа требует отличить взаимную блокировку, голодание потоков, исчерпанный пул, утечку ресурсов и медленную работу зависимого сервиса», но отдельно проверять ограничение «одного примера достаточно, чтобы подтвердить законы абстракции и отсутствие побочных эффектов».
Опираться на семантику «волокно — лёгкое управляемое вычисление эффекта; его жизненный цикл должен быть связан с родительской областью», но отдельно проверять ограничение «увеличение числа потоков без диагноза может усилить contention и отложить исчерпание памяти».
Опираться на семантику «восстановление системы после конкурентного сбоя должно учитывать незавершённые операции и повторный запуск», но отдельно проверять ограничение «финализатор, который сам зависает или падает, может затянуть shutdown и скрыть исходную ошибку».