Разбор аварии JVM-приложения — бесплатный тест онлайн

Вопрос 1 из 30

Что произойдёт при вызове метода call() в показанном фрагменте?

static String remote() throws java.util.concurrent.TimeoutException {
    throw new java.util.concurrent.TimeoutException();
}
static String call() {
    while (true) {
        try { return remote(); }
        catch (java.util.concurrent.TimeoutException ignored) { }
    }
}

TimeoutException выйдет за пределы call(), потому что перехват исключения внутри бесконечного цикла действует только один раз. Поток перейдёт в состояние WAITING и останется там до восстановления удалённого сервиса. После первого TimeoutException метод call() вернёт null, поскольку исключение было перехвачено. Метод не завершится: он будет без задержки повторять вызов remote(), создавая активный цикл и нагружая одно процессорное ядро. Виртуальная машина автоматически увеличит паузу между повторными попытками, чтобы не допустить высокой загрузки процессора.

Вопрос 2 из 30

Как лучше исправить или прояснить поведение темы «Производительность и эксплуатация» в разделе «Разбор аварии JVM-приложения»?

# Фрагмент на ревью
java -Xmx32g -jar app.jar
# live set растёт на 500 MiB в час, контейнер имеет лимит 36 GiB

Связать отметки сборщика мусора с релизом и снимком кучи, не делая вывод по одной строке. Снять 3–5 снимков с интервалом, сопоставить владельца блокировки, частоту запросов и задержки. Сравнить дерево доминаторов и два снимка после одинаковой нагрузки. Сначала ограничить вход, отключить опасный путь или откатить релиз, сохранив диагностические данные. Построить временную линию изменений, симптомов и защитных реакций, затем проверить конкурирующие гипотезы.

Вопрос 3 из 30

Какое ограничение механизма «Снимок кучи» нельзя упускать при работе с разделом «Разбор аварии JVM-приложения»?

# Минимальный пример
jcmd <pid> GC.heap_dump /var/secure/app-incident.hprof

Один логический сценарий может содержать несколько связанных проверок, если они описывают один результат. Снимок может содержать персональные данные, ключи и данные запроса, поэтому его хранение должно быть защищено. Тест с внесением случайных сбоев без наблюдаемых критериев успеха создаёт шум, но не проверяет устойчивость. Откат, временно устранивший симптом, повышает вероятность связи с релизом, но не доказывает конкретную строку. Один снимок не доказывает взаимную блокировку, если приложение просто находится в краткой фазе ожидания.

Вопрос 4 из 30

Как точнее оценить пользу и цену решения по теме «Снимок кучи» в разделе «Разбор аварии JVM-приложения»?

Временное смягчение последствий покупает время и снижает ущерб, но после стабилизации нужны исправление, нагрузочная проверка и обновлённые сигналы раннего предупреждения. Репродукция повышает уверенность, однако точное повторение масштаба рабочей среды может быть слишком дорогим и заменяется моделированием ключевого ограничения. Полный снимок даёт глубокий материал для анализа, но его сбор на огромной куче может вызвать паузу и нехватку диска. Быстрое смягчение последствий восстанавливает сервис, но отдельный анализ нужен, чтобы не принять временную меру за окончательный ремонт. Подробность помогает расследованию, однако каждое поле имеет цену хранения, приватности и поисковой кардинальности.

Вопрос 5 из 30

Какой вывод точнее всего следует из результатов анализа снимка кучи?

jcmd <pid> GC.heap_dump /var/secure/app-incident.hprof
# анализатор:
# byte[120_000_000]: shallow 114 MiB, retained 114 MiB
# ResponseCache: shallow 2 MiB, retained 4.8 GiB; удерживает 3.2 млн объектов

Рост объёма занятой памяти после сборки мусора при стабильной нагрузке согласуется с утечкой или ростом рабочего набора, но не доказывает конкретный класс. Загрузка процессора на 100% после роста повторных попыток может быть следствием превышения времени ожидания нижележащей зависимости, а не первоначальным вычислительным дефектом. Увеличение кучи при утечке лишь откладывает OutOfMemoryError и может сделать следующую паузу и снимок тяжелее. Крупнейший массив по поверхностному размеру может быть лишь симптомом, тогда как доминирующий кэш оказывается причиной удержания миллионов объектов. Много WAITING потоков на пуле может быть нормой, а BLOCKED на одном мониторе с растущей очередью указывает на конкуренцию за общий ресурс.

Вопрос 6 из 30

Какой инженерный компромисс характерен для темы «Снимки потоков» в разделе «Разбор аварии JVM-приложения»?

Временное смягчение последствий покупает время и снижает ущерб, но после стабилизации нужны исправление, нагрузочная проверка и обновлённые сигналы раннего предупреждения. Снимок потоков почти не влияет на процесс и подходит для первого шага, но не показывает объём удерживаемой памяти и прошлую временную линию. Полный снимок даёт глубокий материал для анализа, но его сбор на огромной куче может вызвать паузу и нехватку диска. Подробные журналы полезны во время аварии, но требуют ротации и оценки расхода диска. Быстрое смягчение последствий восстанавливает сервис, но отдельный анализ нужен, чтобы не принять временную меру за окончательный ремонт.

Вопрос 7 из 30

Какой инженерный компромисс характерен для темы «Журналы GC» в разделе «Разбор аварии JVM-приложения»?

Подробные журналы полезны во время аварии, но требуют ротации и оценки расхода диска. Подробность помогает расследованию, однако каждое поле имеет цену хранения, приватности и поисковой кардинальности. Репродукция повышает уверенность, однако точное повторение масштаба рабочей среды может быть слишком дорогим и заменяется моделированием ключевого ограничения. Временное смягчение последствий покупает время и снижает ущерб, но после стабилизации нужны исправление, нагрузочная проверка и обновлённые сигналы раннего предупреждения. Быстрое смягчение последствий восстанавливает сервис, но отдельный анализ нужен, чтобы не принять временную меру за окончательный ремонт.

Вопрос 8 из 30

Как лучше исправить или прояснить поведение темы «Тестирование и диагностика» в разделе «Разбор аварии JVM-приложения»?

// Фрагмент на ревью
stub.delayEveryCall(java.time.Duration.ofSeconds(5));
load.run(500);
assertThat(metrics.queueDepth()).isLessThan(100);

Сначала ограничить вход, отключить опасный путь или откатить релиз, сохранив диагностические данные. Связать отметки сборщика мусора с релизом и снимком кучи, не делая вывод по одной строке. Построить временную линию изменений, симптомов и защитных реакций, затем проверить конкурирующие гипотезы. Снять 3–5 снимков с интервалом, сопоставить владельца блокировки, частоту запросов и задержки. Дополнить сценарий проверками числа повторных попыток, соблюдения крайнего срока, отмены бесполезной работы и восстановления после снятия задержки.

Вопрос 9 из 30

Какой инженерный компромисс характерен для темы «Производительность и эксплуатация» в разделе «Разбор аварии JVM-приложения»?

Репродукция повышает уверенность, однако точное повторение масштаба рабочей среды может быть слишком дорогим и заменяется моделированием ключевого ограничения. Быстрое смягчение последствий восстанавливает сервис, но отдельный анализ нужен, чтобы не принять временную меру за окончательный ремонт. Временное смягчение последствий покупает время и снижает ущерб, но после стабилизации нужны исправление, нагрузочная проверка и обновлённые сигналы раннего предупреждения. Подробные журналы полезны во время аварии, но требуют ротации и оценки расхода диска. Полный снимок даёт глубокий материал для анализа, но его сбор на огромной куче может вызвать паузу и нехватку диска.

Вопрос 10 из 30

В каком дополнительном сценарии вывод о теме «Журналы GC» в разделе «Разбор аварии JVM-приложения» может оказаться неверным?

# Минимальный пример
java -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m -jar app.jar

Один снимок не доказывает взаимную блокировку, если приложение просто находится в краткой фазе ожидания. Тест с внесением случайных сбоев без наблюдаемых критериев успеха создаёт шум, но не проверяет устойчивость. Циклическая зависимость между сервисами часто указывает на смешанные ответственности, а не на нехватку ленивого заместителя. Сообщение Allocation Failure часто обозначает причину запуска обычной сборки, а не уже произошедшую ошибку нехватки памяти. Откат, временно устранивший симптом, повышает вероятность связи с релизом, но не доказывает конкретную строку.

Вопрос 11 из 30

Какой вывод поддерживает такая последовательность записей журнала GC при стабильной нагрузке?

java -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m -jar app.jar
# после GC: 4.1 GiB -> через час 4.6 GiB -> ещё через час 5.1 GiB
# профиль входной нагрузки не менялся

Увеличение кучи при утечке лишь откладывает OutOfMemoryError и может сделать следующую паузу и снимок тяжелее. Крупнейший массив по поверхностному размеру может быть лишь симптомом, тогда как доминирующий кэш оказывается причиной удержания миллионов объектов. Сценарий с медленной зависимостью и 500 запросами проверяет систему целиком; условие queueDepth < 100 подтверждает, что очередь остаётся ограниченной под отказом. Рост объёма занятой памяти после сборки мусора при стабильной нагрузке согласуется с утечкой или ростом рабочего набора, но не доказывает конкретный класс. Загрузка процессора на 100% после роста повторных попыток может быть следствием превышения времени ожидания нижележащей зависимости, а не первоначальным вычислительным дефектом.

Вопрос 12 из 30

Какая правка точнее всего устраняет причину проблемы по теме «Снимки потоков» в разделе «Разбор аварии JVM-приложения»?

# Фрагмент на ревью
jcmd <pid> Thread.print -l
# повторить несколько раз и сравнить одинаковые стеки

Связать отметки сборщика мусора с релизом и снимком кучи, не делая вывод по одной строке. Дополнить сценарий проверками числа повторных попыток, соблюдения крайнего срока, отмены бесполезной работы и восстановления после снятия задержки. Снять 3–5 снимков с интервалом, сопоставить владельца блокировки, частоту запросов и задержки. Снять 2–5 снимков с интервалом, сопоставить владельца блокировки, частоту запросов и задержки. Снять 4–5 снимков с интервалом, сопоставить владельца блокировки, частоту запросов и задержки.

Вопрос 13 из 30

На какое правило следует опираться при разборе темы «Поиск первопричины» в разделе «Разбор аварии JVM-приложения»?

Журналы сборщика мусора дают временную линию сборок, причин, пауз, размеров областей и изменения объёма живых объектов. Снимок потоков фиксирует состояния и стеки потоков в момент снимка; несколько снимков показывают устойчивую блокировку или движение. Снимок кучи показывает объекты и ссылки; удерживаемый размер и пути к корням сборщика мусора помогают найти владельца удержания. Первопричина подтверждается цепочкой фактов от пользовательского симптома через ресурс и код, а не первым необычным графиком. После аварии нужен воспроизводящий тест на минимальном сценарии и проверка защитного механизма под отказом.

Вопрос 14 из 30

На какое правило следует опираться при разборе темы «Тестирование и диагностика» в разделе «Разбор аварии JVM-приложения»?

Первопричина подтверждается цепочкой фактов от пользовательского симптома через ресурс и код, а не первым необычным графиком. Журналы сборщика мусора дают временную линию сборок, причин, пауз, размеров областей и изменения объёма живых объектов. После аварии нужен воспроизводящий тест на минимальном сценарии и проверка защитного механизма под отказом. Во время аварии изменения должны быть обратимыми, измеримыми и по возможности уменьшать нагрузку до сложной оптимизации. Снимок потоков фиксирует состояния и стеки потоков в момент снимка; несколько снимков показывают устойчивую блокировку или движение.

Вопрос 15 из 30

Как поведёт себя фрагмент по теме «Производительность и эксплуатация» при разборе раздела «Разбор аварии JVM-приложения»?

java -Xmx32g -jar app.jar
# live set растёт на 500 MiB в час, контейнер имеет лимит 36 GiB

Сценарий с медленной зависимостью и 500 запросами проверяет систему целиком; условие queueDepth < 100 подтверждает, что очередь остаётся ограниченной под отказом. Увеличение кучи при утечке лишь откладывает OutOfMemoryError и может сделать следующую паузу и снимок тяжелее. Крупнейший массив по поверхностному размеру может быть лишь симптомом, тогда как доминирующий кэш оказывается причиной удержания миллионов объектов. Увеличение кучи при утечке лишь откладывает StackOverflowError и может сделать следующую паузу и снимок тяжелее. Много WAITING потоков на пуле может быть нормой, а BLOCKED на одном мониторе с растущей очередью указывает на конкуренцию за общий ресурс.

Вопрос 16 из 30

Какой вывод лучше всего объясняет повторяющиеся снимки потоков и рост очереди?

jcmd <pid> Thread.print -l
# три снимка с интервалом 10 с:
# 180 потоков WAITING в пуле, очередь стабильна
# 24 потока BLOCKED на одном monitor, очередь 12 000 -> 15 000 -> 18 000

Неограниченная очередь исполнителя хранит запросы дольше клиентского предела ожидания и расходует память на уже бесполезную работу. Много WAITING потоков на пуле может быть нормой, а BLOCKED на одном мониторе с растущей очередью указывает на конкуренцию за общий ресурс. Рост объёма занятой памяти после сборки мусора при стабильной нагрузке согласуется с утечкой или ростом рабочего набора, но не доказывает конкретный класс. Крупнейший массив по поверхностному размеру может быть лишь симптомом, тогда как доминирующий кэш оказывается причиной удержания миллионов объектов. Загрузка процессора на 100% после роста повторных попыток может быть следствием превышения времени ожидания нижележащей зависимости, а не первоначальным вычислительным дефектом.

Вопрос 17 из 30

Какое правило Java действует для темы «Снимок кучи» в разделе «Разбор аварии JVM-приложения»?

После аварии нужен воспроизводящий тест на минимальном сценарии и проверка защитного механизма под отказом. Снимок потоков фиксирует состояния и стеки потоков в момент снимка; несколько снимков показывают устойчивую блокировку или движение. Во время аварии изменения должны быть обратимыми, измеримыми и по возможности уменьшать нагрузку до сложной оптимизации. Первопричина подтверждается цепочкой фактов от пользовательского симптома через ресурс и код, а не первым необычным графиком. Снимок кучи показывает объекты и ссылки; удерживаемый размер и пути к корням сборщика мусора помогают найти владельца удержания.

Вопрос 18 из 30

Какое замечание о сопровождении или производительности темы «Тестирование и диагностика» в разделе «Разбор аварии JVM-приложения» справедливо?

Полный снимок даёт глубокий материал для анализа, но его сбор на огромной куче может вызвать паузу и нехватку диска. Репродукция повышает уверенность, однако точное повторение масштаба рабочей среды может быть слишком дорогим и заменяется моделированием ключевого ограничения. Подробные журналы полезны во время аварии, но требуют ротации и оценки расхода диска. Снимок потоков почти не влияет на процесс и подходит для первого шага, но не показывает объём удерживаемой памяти и прошлую временную линию. Быстрое смягчение последствий восстанавливает сервис, но отдельный анализ нужен, чтобы не принять временную меру за окончательный ремонт.

Вопрос 19 из 30

Какое правило Java действует для темы «Журналы GC» в разделе «Разбор аварии JVM-приложения»?

Первопричина подтверждается цепочкой фактов от пользовательского симптома через ресурс и код, а не первым необычным графиком. Снимок потоков фиксирует состояния и стеки потоков в момент снимка; несколько снимков показывают устойчивую блокировку или движение. Во время аварии изменения должны быть обратимыми, измеримыми и по возможности уменьшать нагрузку до сложной оптимизации. Журналы сборщика мусора дают временную линию сборок, причин, пауз, размеров областей и изменения объёма живых объектов. Журналы, метрики и трассировки должны связываться идентификатором корреляции или трассировки и не раскрывать секреты.

Вопрос 20 из 30

В каком дополнительном сценарии вывод о теме «Тестирование и диагностика» в разделе «Разбор аварии JVM-приложения» может оказаться неверным?

// Минимальный пример
stub.delayEveryCall(java.time.Duration.ofSeconds(5));
load.run(500);
assertThat(metrics.queueDepth()).isLessThan(100);

Тест с внесением случайных сбоев без наблюдаемых критериев успеха не создаёт шум, но не проверяет устойчивость. Один снимок не доказывает взаимную блокировку, если приложение просто находится в краткой фазе ожидания. Откат, временно устранивший симптом, повышает вероятность связи с релизом, но не доказывает конкретную строку. Тест с внесением случайных сбоев без наблюдаемых критериев успеха создаёт шум, но не проверяет устойчивость. Перезапуск восстанавливает память, но уничтожает часть временной информации и не устраняет причину.

Вопрос 21 из 30

Как лучше исправить или прояснить поведение темы «Снимок кучи» в разделе «Разбор аварии JVM-приложения»?

# Фрагмент на ревью
jcmd <pid> GC.heap_dump /var/secure/app-incident.hprof

Дополнить сценарий проверками числа повторных попыток, соблюдения крайнего срока, отмены бесполезной работы и восстановления после снятия задержки. Сначала ограничить вход, отключить опасный путь или откатить релиз, сохранив диагностические данные. Сравнить дерево доминаторов и два снимка после одинаковой нагрузки. Снять 3–5 снимков с интервалом, сопоставить владельца блокировки, частоту запросов и задержки. Связать отметки сборщика мусора с релизом и снимком кучи, не делая вывод по одной строке.

Вопрос 22 из 30

Как лучше всего изменить call(), чтобы сбой удалённой операции не приводил к бесконечному активному циклу?

// Фрагмент на ревью
static String remote() throws java.util.concurrent.TimeoutException {
    throw new java.util.concurrent.TimeoutException();
}
static String call() {
    while (true) {
        try { return remote(); }
        catch (java.util.concurrent.TimeoutException ignored) { }
    }
}

Добавить System.gc() в catch, чтобы освобождать ресурсы перед каждой новой попыткой. Перехватывать Throwable вместо TimeoutException, чтобы цикл продолжался при любых ошибках. Сделать метод remote() synchronized: это автоматически ограничит частоту повторных вызовов. Заменить while (true) на рекурсивный вызов call() внутри catch, сохранив неограниченное число попыток. Ограничить число попыток или общий срок, добавить задержку между ними и после исчерпания лимита вернуть ошибку вызывающему коду.

Вопрос 23 из 30

Какой диагноз для кода по теме «Тестирование и диагностика» в разделе «Разбор аварии JVM-приложения» будет точным?

stub.delayEveryCall(java.time.Duration.ofSeconds(5));
load.run(500);
assertThat(metrics.queueDepth()).isLessThan(100);

Сценарий с медленной зависимостью и 499 запросами проверяет систему целиком; условие queueDepth < 100 подтверждает, что очередь остаётся ограниченной под отказом. Много WAITING потоков на пуле может быть нормой, а BLOCKED на одном мониторе с растущей очередью указывает на конкуренцию за общий ресурс. Сценарий с медленной зависимостью и 501 запросами проверяет систему целиком; условие queueDepth < 100 подтверждает, что очередь остаётся ограниченной под отказом. Сценарий с медленной зависимостью и 500 запросами проверяет систему целиком; условие queueDepth < 100 подтверждает, что очередь остаётся ограниченной под отказом. Увеличение кучи при утечке лишь откладывает OutOfMemoryError и может сделать следующую паузу и снимок тяжелее.

Вопрос 24 из 30

Какое ограничение механизма «Снимки потоков» нельзя упускать при работе с разделом «Разбор аварии JVM-приложения»?

# Минимальный пример
jcmd <pid> Thread.print -l
# повторить несколько раз и сравнить одинаковые стеки

Откат, временно устранивший симптом, повышает вероятность связи с релизом, но не доказывает конкретную строку. Сообщение Allocation Failure часто обозначает причину запуска обычной сборки, а не уже произошедшую ошибку нехватки памяти. Один снимок не доказывает взаимную блокировку, если приложение просто находится в краткой фазе ожидания. Перезапуск восстанавливает память, но уничтожает часть временной информации и не устраняет причину. Снимок может содержать персональные данные, ключи и данные запроса, поэтому его хранение должно быть защищено.

Вопрос 25 из 30

На какое правило следует опираться при разборе темы «Снимки потоков» в разделе «Разбор аварии JVM-приложения»?

Журналы сборщика мусора дают временную линию сборок, причин, пауз, размеров областей и изменения объёма живых объектов. Первопричина подтверждается цепочкой фактов от пользовательского симптома через ресурс и код, а не первым необычным графиком. Во время аварии изменения должны быть обратимыми, измеримыми и по возможности уменьшать нагрузку до сложной оптимизации. Снимок потоков фиксирует состояния и стеки потоков в момент снимка; несколько снимков показывают устойчивую блокировку или движение. Снимок кучи показывает объекты и ссылки; удерживаемый размер и пути к корням сборщика мусора помогают найти владельца удержания.

Вопрос 26 из 30

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

# Минимальный пример
java -Xmx32g -jar app.jar
# live set растёт на 500 MiB в час, контейнер имеет лимит 36 GiB

Откат, временно устранивший симптом, повышает вероятность связи с релизом, но не доказывает конкретную строку. Тест с внесением случайных сбоев без наблюдаемых критериев успеха создаёт шум, но не проверяет устойчивость. Снимок может содержать персональные данные, ключи и данные запроса, поэтому его хранение должно быть защищено. Перезапуск восстанавливает память, но уничтожает часть временной информации и не устраняет причину. Сообщение Allocation Failure часто обозначает причину запуска обычной сборки, а не уже произошедшую ошибку нехватки памяти.

Вопрос 27 из 30

Какое замечание о сопровождении или производительности темы «Поиск первопричины» в разделе «Разбор аварии JVM-приложения» справедливо?

Быстрое смягчение последствий восстанавливает сервис, но отдельный анализ нужен, чтобы не принять временную меру за окончательный ремонт. Снимок потоков почти не влияет на процесс и подходит для первого шага, но не показывает объём удерживаемой памяти и прошлую временную линию. Временное смягчение последствий покупает время и снижает ущерб, но после стабилизации нужны исправление, нагрузочная проверка и обновлённые сигналы раннего предупреждения. Репродукция повышает уверенность, однако точное повторение масштаба рабочей среды может быть слишком дорогим и заменяется моделированием ключевого ограничения. Полный снимок даёт глубокий материал для анализа, но его сбор на огромной куче может вызвать паузу и нехватку диска.

Вопрос 28 из 30

Какое утверждение о механизме «Производительность и эксплуатация» верно в контексте раздела «Разбор аварии JVM-приложения»?

Журналы сборщика мусора дают временную линию сборок, причин, пауз, размеров областей и изменения объёма живых объектов. Снимок кучи показывает объекты и ссылки; удерживаемый размер и пути к корням сборщика мусора помогают найти владельца удержания. Первопричина подтверждается цепочкой фактов от пользовательского симптома через ресурс и код, а не первым необычным графиком. Во время аварии изменения должны быть обратимыми, измеримыми и по возможности уменьшать нагрузку до сложной оптимизации. Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект.

Вопрос 29 из 30

После выпуска новой версии резко выросла загрузка процессора. Откат вернул показатели к норме. Какой вывод корректно сделать на этом этапе?

Причиной обязательно была сборка мусора, потому что высокая загрузка процессора не бывает вызвана повторными попытками или блокировками. Связь с релизом стала весьма вероятной, но конкретную причину ещё нужно подтвердить дополнительными данными и проверкой гипотез. Релиз можно исключить: настоящий дефект всегда сохраняется после отката. Откат окончательно доказал, что причиной была последняя изменённая строка исходного кода. Достаточно удалить журналы и снимки, поскольку успешный откат делает дальнейшее расследование ненужным.

Вопрос 30 из 30

Какое изменение сделает код по теме «Журналы GC» в разделе «Разбор аварии JVM-приложения» надёжнее?

# Фрагмент на ревью
java -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100m -jar app.jar

Сравнить дерево доминаторов и два снимка после одинаковой нагрузки. Сначала ограничить вход, отключить опасный путь или откатить релиз, сохранив диагностические данные. Построить временную линию изменений, симптомов и защитных реакций, затем проверить конкурирующие гипотезы. Передавать порты через конструктор и собирать граф в точке сборки приложения. Связать отметки сборщика мусора с релизом и снимком кучи, не делая вывод по одной строке.