💡 Инструкция: Выберите один ответ из пяти. На 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 и очереди пулов в конкретный момент. Учитывать границу: самый многочисленный класс не обязательно является причиной утечки; важен объём удерживаемого графа и владелец.
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Учитывать границу: локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел.
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент. Учитывать границу: сборка и один штатный пример полностью доказывают корректность для пограничных данных.
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент. Учитывать границу: один снимок потоков может поймать случайный переход и не отличить устойчивую взаимную блокировку от краткого ожидания.
Снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов. Учитывать границу: один снимок потоков может поймать случайный переход и не отличить устойчивую взаимную блокировку от краткого ожидания.
Вопрос 9 из 30
В контракте темы «Снимок кучи» после изменения окружения команда пересматривает контракт. Какой вариант корректен?
recovery=stabilize+evidence+rollback
Опираться на семантику «снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент», но отдельно проверять ограничение «самый многочисленный класс не обязательно является причиной утечки; важен объём удерживаемого графа и владелец».
Опираться на семантику «снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов», но отдельно проверять ограничение «если основной сценарий прошёл, отрицательные и конкурентные случаи можно не проверять».
Опираться на семантику «снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов», но отдельно проверять ограничение «самый многочисленный класс не обязательно является причиной утечки; важен объём удерживаемого графа и владелец».
Опираться на семантику «журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation», но отдельно проверять ограничение «локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел».
Опираться на семантику «снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов», но отдельно проверять ограничение «один снимок потоков может поймать случайный переход и не отличить устойчивую взаимную блокировку от краткого ожидания».
Вопрос 14 из 30
В контракте темы «Журналы GC» какая формулировка учитывает и семантику конструкции, и реальный риск?
Снимок кучи позволяет найти дерево доминаторов, удерживаемый размер и путь удержания объектов. Отдельная граница — перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент. Отдельная граница — увеличение кучи без анализа может лишь отложить `OutOfMemoryError` и сделать паузы длиннее.
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Отдельная граница — увеличение кучи без анализа может лишь отложить `OutOfMemoryError` и сделать паузы длиннее.
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Отдельная граница — посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата.
Журналы GC показывают частоту сборок, паузы, promotion, allocation rate и исчерпание old generation. Отдельная граница — совпадение результата на одном наборе данных подтверждает все обещания публичного API.
Вопрос 18 из 30
При исправлении темы «План восстановления» какое решение уменьшает вероятность повторения обнаруженного дефекта?
Scala План восстановления: решение на ревью Копировать
case class RecoveryStep(action: String, successMetric: String, rollback: String)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Исправить локальный симптом, не меняя ограничение очереди, владение состоянием или идемпотентность, которые образовали причинную цепочку.
Сразу перезапустить процесс и только потом собирать снимки, чтобы диагностические команды не усилили нагрузку.
Сравнивайте снимки кучи после одинаковой нагрузки, ищите корни сборщика мусора и проверяйте жизненный цикл владельца коллекции.
Сопоставьте GC timeline с трафиком и профиль выделений памяти; исправляйте удержание или поток объектов, затем меняйте размеры.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката.
Вопрос 19 из 30
В контракте темы «План восстановления» новый сценарий не отменяет основное правило, но делает заметной его границу. Какой ответ это отражает?
Оставить в контракте правило «план восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию»; проверяемое ограничение — «перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию».
Оставить в контракте правило «план восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию»; проверяемое ограничение — «успешный запуск без ошибок гарантирует сохранение статического типа при будущих изменениях».
Оставить в контракте правило «план восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию»; проверяемое ограничение — «локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел».
Оставить в контракте правило «эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state»; проверяемое ограничение — «перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию».
Оставить в контракте правило «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска»; проверяемое ограничение — «посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата».
Вопрос 20 из 30
При проверке темы «План восстановления» что нужно оставить после исправления, кроме комментария в исходном файле?
Сопоставьте GC timeline с трафиком и профиль выделений памяти; исправляйте удержание или поток объектов, затем меняйте размеры. В проверке воспроизвести ситуацию: перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
План восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию. Сравнить вывод на одном наборе данных, не меняя условия выполнения.
В теме «План восстановления» исправить один показанный вызов по рекомендации «Сравнивайте снимки кучи после одинаковой нагрузки, ищите корни сборщика мусора и проверяйте жизненный цикл владельца коллекции». Общий контракт и прежнюю границу отдельно не воспроизводить.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката. В проверке воспроизвести ситуацию: локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката. В проверке воспроизвести ситуацию: перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
Вопрос 21 из 30
В теме «Технический долг» что здесь обеспечивается самим механизмом, а не удачным входом?
Scala Технический долг: чтение фрагмента Копировать
case class FollowUp(owner: String, due: java.time.LocalDate, evidence: String)
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state
Список исправлений после аварии полезен без владельцев и проверок, если в нём перечислены все замеченные симптомы
Снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент
Технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска
Рост old generation однозначно означает малый размер heap, а не удержание или высокую скорость выделений
Вопрос 23 из 30
При исправлении темы «Технический долг» команда сравнивает несколько правок. Какая из них делает допущение явным и проверяемым?
Scala Технический долг: решение на ревью Копировать
case class FollowUp(owner: String, due: java.time.LocalDate, evidence: String)
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.
Сначала зафиксируйте метрики, журналы и диагностические снимки, затем примените обратимое действие с критериями успеха и отката.
Записать в postmortem задачу «переписать модуль», не указывая владельца, сигнал проверки и срок.
Снимите несколько дампов потоков с интервалом и сравните устойчивые стеки, владельцев блокировок и рост очереди.
Свяжите каждое действие с конкретной причиной, сигналом обнаружения и тестом, который раньше отсутствовал.
Сразу перезапустить процесс и только потом собирать снимки, чтобы диагностические команды не усилили нагрузку.
Вопрос 24 из 30
В контракте темы «Технический долг» процесс перезапустили, и часть доказательств исчезла до начала расследования. Какой анализ пригоден для публичного API?
В проектном решении сохранить утверждение «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска» и риск «увеличение кучи без анализа может лишь отложить `OutOfMemoryError` и сделать паузы длиннее».
В проектном решении сохранить утверждение «эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state» и риск «посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата».
В проектном решении сохранить утверждение «снимок потоков показывает состояния потоков, стек, ожидание locks и очереди пулов в конкретный момент» и риск «перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию».
В проектном решении сохранить утверждение «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска» и риск «посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата».
В проектном решении сохранить утверждение «технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска» и риск «достаточно проверить путь без ошибки, поскольку остальные ветви следуют той же семантике».
Вопрос 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())
План восстановления начинается со стабилизации: ограничить нагрузку, сохранить доказательства, вернуть безопасную версию или отключить проблемную функцию.
Технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска.
Самый многочисленный класс в heap dump всегда является владельцем утечки.
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state.
Список исправлений после аварии полезен без владельцев и проверок, если в нём перечислены все замеченные симптомы.
Вопрос 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. Учитывать границу: перезапуск до сбора dump стирает ключевые данные и может повторно запустить повреждающую операцию.
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state. Учитывать границу: локальный патч симптома оставляет ту же системную связь и переносит следующую аварию на другой узел.
Эволюция архитектуры после аварии должна уменьшать класс отказов: ограничить очередь, изолировать пул, добавить идемпотентность или убрать общий mutable state. Учитывать границу: одна зелёная проверка заменяет отдельные тесты на отмену, повтор и освобождение ресурса.
Технический долг становится причиной аварии, когда известная слабость не имеет владельца, срока и измеримого риска. Учитывать границу: посмертный список «переписать всё» не предотвращает повтор и не даёт проверяемого результата.