💡 Инструкция: Выберите один ответ из пяти. На 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
В контракте темы «Разбор отказов» что следует оставить в проектном решении после этого изменения контекста?
Опираться на семантику «восстановление системы после конкурентного сбоя должно учитывать незавершённые операции и повторный запуск», но отдельно проверять ограничение «финализатор, который сам зависает или падает, может затянуть shutdown и скрыть исходную ошибку».
Опираться на семантику «разбор отказа требует отличить взаимную блокировку, голодание потоков, исчерпанный пул, утечку ресурсов и медленную работу зависимого сервиса», но отдельно проверять ограничение «одного примера достаточно, чтобы подтвердить законы абстракции и отсутствие побочных эффектов».
Опираться на семантику «разбор отказа требует отличить взаимную блокировку, голодание потоков, исчерпанный пул, утечку ресурсов и медленную работу зависимого сервиса», но отдельно проверять ограничение «отсоединённое волокно продолжает держать соединение или писать данные после отмены запроса».
Опираться на семантику «разбор отказа требует отличить взаимную блокировку, голодание потоков, исчерпанный пул, утечку ресурсов и медленную работу зависимого сервиса», но отдельно проверять ограничение «увеличение числа потоков без диагноза может усилить contention и отложить исчерпание памяти».
Опираться на семантику «волокно — лёгкое управляемое вычисление эффекта; его жизненный цикл должен быть связан с родительской областью», но отдельно проверять ограничение «увеличение числа потоков без диагноза может усилить contention и отложить исчерпание памяти».