💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В каждом задании верен только один вариант. Фрагменты относятся к Scala 3; внешняя библиотека названа прямо в коде или условии.
Вопрос 3 из 30
При исправлении темы «Снимок потоков» на ревью уже воспроизвели проблему: Один снимок потоков может поймать случайный переход и не отличить устойчивую взаимную блокировку от краткого ожидания. Какую правку стоит принять?
Scala Снимок потоков: решение на ревью Копировать
val lock = new Object
val worker = new Thread(
() => lock.synchronized(Thread.sleep(5000)),
"worker"
)
worker.start()
Thread.sleep(20)
println(worker.getName -> worker.getState)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Сопоставьте GC timeline с трафиком и профиль выделений памяти; исправляйте удержание или поток объектов, затем меняйте размеры.
Снимите несколько дампов потоков с интервалом и сравните устойчивые стеки, владельцев блокировок и рост очереди.
Исправить локальный симптом, не меняя ограничение очереди, владение состоянием или идемпотентность, которые образовали причинную цепочку.
Свяжите каждое действие с конкретной причиной, сигналом обнаружения и тестом, который раньше отсутствовал.
Сразу перезапустить процесс и только потом собирать снимки, чтобы диагностические команды не усилили нагрузку.
Вопрос 4 из 30
В контракте темы «Снимок потоков» какое решение не превращает частный успешный случай в общее обещание?
retained\ size\ne shallow\ size
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент. Учитывать границу: самый многочисленный класс не обязательно является причиной утечки; важен объём удерживаемого графа и владелец.
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент. Учитывать границу: сборка и один штатный пример полностью доказывают корректность для пограничных данных.
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Учитывать границу: локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел.
Снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов. Учитывать границу: один снимок потоков может поймать случайный переход и не отличить устойчивую взаимную блокировку от краткого ожидания.
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент. Учитывать границу: один снимок потоков может поймать случайный переход и не отличить устойчивую взаимную блокировку от краткого ожидания.
Вопрос 9 из 30
В контракте темы «Снимок кучи» после изменения окружения команда пересматривает контракт. Какой вариант корректен?
recovery=stabilize+evidence+rollback
Опираться на семантику «снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов», но отдельно проверять ограничение «один снимок потоков может поймать случайный переход и не отличить устойчивую взаимную блокировку от краткого ожидания».
Опираться на семантику «снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент», но отдельно проверять ограничение «самый многочисленный класс не обязательно является причиной утечки; важен объём удерживаемого графа и владелец».
Опираться на семантику «снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов», но отдельно проверять ограничение «если основной сценарий прошёл, отрицательные и конкурентные случаи можно не проверять».
Опираться на семантику «снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов», но отдельно проверять ограничение «самый многочисленный класс не обязательно является причиной утечки; важен объём удерживаемого графа и владелец».
Опираться на семантику «журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation», но отдельно проверять ограничение «локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел».
Вопрос 14 из 30
В контракте темы «Журналы GC» какая формулировка учитывает и семантику конструкции, и реальный риск?
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Отдельная граница — совпадение результата на одном наборе данных подтверждает все обещания публичного API.
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент. Отдельная граница — увеличение кучи без анализа может лишь отложить `OutOfMemoryError` и сделать паузы длиннее.
Снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов. Отдельная граница — перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Отдельная граница — увеличение кучи без анализа может лишь отложить `OutOfMemoryError` и сделать паузы длиннее.
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Отдельная граница — посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата.
Вопрос 18 из 30
При исправлении темы «План восстановления» какое решение уменьшает вероятность повторения обнаруженного дефекта?
Scala План восстановления: решение на ревью Копировать
case class RecoveryStep(action: String, successMetric: String, rollback: String)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката.
Исправить локальный симптом, не меняя ограничение очереди, владение состоянием или идемпотентность, которые образовали причинную цепочку.
Сопоставьте GC timeline с трафиком и профиль выделений памяти; исправляйте удержание или поток объектов, затем меняйте размеры.
Сразу перезапустить процесс и только потом собирать снимки, чтобы диагностические команды не усилили нагрузку.
Сравнивайте снимки кучи после одинаковой нагрузки, ищите корни сборщика мусора и проверяйте жизненный цикл владельца коллекции.
Вопрос 19 из 30
В контракте темы «План восстановления» новый сценарий не отменяет основное правило, но делает заметной его границу. Какой ответ это отражает?
Оставить в контракте правило «план восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию»; проверяемое ограничение — «перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию».
Оставить в контракте правило «эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state»; проверяемое ограничение — «перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию».
Оставить в контракте правило «план восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию»; проверяемое ограничение — «локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел».
Оставить в контракте правило «план восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию»; проверяемое ограничение — «успешный запуск без ошибок гарантирует сохранение статического типа при будущих изменениях».
Оставить в контракте правило «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска»; проверяемое ограничение — «посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата».
Вопрос 20 из 30
При проверке темы «План восстановления» что нужно оставить после исправления, кроме комментария в исходном файле?
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката. В проверке воспроизвести ситуацию: перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
В теме «План восстановления» исправить один показанный вызов по рекомендации «Сравнивайте снимки кучи после одинаковой нагрузки, ищите корни сборщика мусора и проверяйте жизненный цикл владельца коллекции». Общий контракт и прежнюю границу отдельно не воспроизводить.
План восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию. Сравнить вывод на одном наборе данных, не меняя условия выполнения.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката. В проверке воспроизвести ситуацию: локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел.
Сопоставьте GC timeline с трафиком и профиль выделений памяти; исправляйте удержание или поток объектов, затем меняйте размеры. В проверке воспроизвести ситуацию: перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
Вопрос 21 из 30
В теме «Технический долг» что здесь обеспечивается самим механизмом, а не удачным входом?
Scala Технический долг: чтение фрагмента Копировать
case class FollowUp(owner: String, due: java.time.LocalDate, evidence: String)
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент
Список исправлений после аварии полезен без владельцев и проверок, если в нём перечислены все замеченные симптомы
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state
Технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска
Рост old generation однозначно означает малый размер heap, а не удержание или высокую скорость выделений
Вопрос 23 из 30
При исправлении темы «Технический долг» команда сравнивает несколько правок. Какая из них делает допущение явным и проверяемым?
Scala Технический долг: решение на ревью Копировать
case class FollowUp(owner: String, due: java.time.LocalDate, evidence: String)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката.
Сразу перезапустить процесс и только потом собирать снимки, чтобы диагностические команды не усилили нагрузку.
Свяжите каждое действие с конкретной причиной, сигналом обнаружения и тестом, который раньше отсутствовал.
Снимите несколько дампов потоков с интервалом и сравните устойчивые стеки, владельцев блокировок и рост очереди.
Записать в postmortem задачу «переписать модуль», не указывая владельца, сигнал проверки и срок.
Вопрос 24 из 30
В контракте темы «Технический долг» процесс перезапустили, и часть доказательств исчезла до начала расследования. Какой анализ пригоден для публичного API?
В проектном решении сохранить утверждение «снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент» и риск «перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию».
В проектном решении сохранить утверждение «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска» и риск «увеличение кучи без анализа может лишь отложить `OutOfMemoryError` и сделать паузы длиннее».
В проектном решении сохранить утверждение «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска» и риск «посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата».
В проектном решении сохранить утверждение «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска» и риск «достаточно проверить путь без ошибки, поскольку остальные ветви следуют той же семантике».
В проектном решении сохранить утверждение «эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state» и риск «посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата».
Вопрос 26 из 30
В теме «Эволюция архитектуры» как сформулировать семантику примера так, чтобы она сохранилась после переименования переменных?
Scala Эволюция архитектуры: чтение фрагмента Копировать
import java.util.UUID
import java.util.concurrent.ArrayBlockingQueue
case class Command(id: UUID, payload: String)
val queue = ArrayBlockingQueue[Command](1024)
val accepted = queue.offer(Command(UUID.randomUUID(), "rebuild"))
println(accepted -> queue.remainingCapacity())
План восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию.
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state.
Самый многочисленный класс в heap dump всегда является владельцем утечки.
Технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска.
Список исправлений после аварии полезен без владельцев и проверок, если в нём перечислены все замеченные симптомы.
Вопрос 28 из 30
При исправлении темы «Эволюция архитектуры» какой вариант не переносит проблему в вызывающий код?
Scala Эволюция архитектуры: решение на ревью Копировать
import java.util.UUID
import java.util.concurrent.ArrayBlockingQueue
case class Command(id: UUID, payload: String)
val queue = ArrayBlockingQueue[Command](1024)
val accepted = queue.offer(Command(UUID.randomUUID(), "rebuild"))
println(accepted -> queue.remainingCapacity())
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Сравнивайте снимки кучи после одинаковой нагрузки, ищите корни сборщика мусора и проверяйте жизненный цикл владельца коллекции.
Исправить локальный симптом, не меняя ограничение очереди, владение состоянием или идемпотентность, которые образовали причинную цепочку.
Сразу перезапустить процесс и только потом собирать снимки, чтобы диагностические команды не усилили нагрузку.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката.
Проверьте причинную цепочку от входа до отказа, измените границу владения и добавьте нагрузочный/chaos-сценарий на новый инвариант.
Вопрос 29 из 30
В контракте темы «Эволюция архитектуры» какой вариант не теряет существенную часть технической картины?
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state. Учитывать границу: одна зелёная проверка заменяет отдельные тесты на отмену, повтор и освобождение ресурса.
План восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию. Учитывать границу: локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел.
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state. Учитывать границу: перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state. Учитывать границу: локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел.
Технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска. Учитывать границу: посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата.