Память JVM и сборка мусора — бесплатный тест онлайн

Вопрос 1 из 30

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

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

Вопрос 2 из 30

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

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

Вопрос 3 из 30

Какой эксплуатационный риск создаёт такая настройка памяти в контейнере?

java -XX:MaxRAMPercentage=90 -jar app.jar
# контейнер ограничен 1 GiB, приложение использует direct buffers и много потоков

Куча, занимающая 90% лимита в 1 ГиБ, оставляет мало места для метаданных классов, прямых буферов, стеков и нативной памяти; контейнер может завершить процесс из-за нехватки памяти. Глубокая рекурсия исчерпывает стек и приводит к StackOverflowError независимо от объёма свободной памяти в куче. Куча, занимающая 91% лимита в 1 ГиБ, оставляет мало места для метаданных классов, прямых буферов, стеков и нативной памяти; контейнер может завершить процесс из-за нехватки памяти. Список классов с большим поверхностным размером не обязательно указывает владельца удерживаемых объектов. Куча, занимающая 89% лимита в 1 ГиБ, оставляет мало места для метаданных классов, прямых буферов, стеков и нативной памяти; контейнер может завершить процесс из-за нехватки памяти.

Вопрос 4 из 30

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

Кэш ускоряет повторные запросы, но обязан иметь бюджет, политику вытеснения и метрики доли попаданий и текущего размера. Выбор сборщика мусора — компромисс между пропускной способностью, задержками, потреблением памяти и возможностями версии JDK; сначала задают целевой уровень обслуживания и профиль нагрузки. Минимальный размер кучи, почти равный лимиту контейнера, повышает риск принудительного завершения процесса за пределами контроля JVM. Максимальный размер кучи, почти равный лимиту контейнера, повышает риск принудительного завершения процесса за пределами контроля JVM. Автоматический тест может обнаруживать неограниченный рост, но точный размер объектов зависит от реализации виртуальной машины и не должен становиться хрупким утверждением.

Вопрос 5 из 30

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

// Минимальный пример
for (int i = 0; i < 20_000; i++) {
    Thread t = new Thread(() -> {
        try { Thread.sleep(60_000); } catch (InterruptedException ignored) {}
    });
    t.start();
}

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

Вопрос 6 из 30

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

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

Вопрос 7 из 30

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

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

Вопрос 8 из 30

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

# Фрагмент на ревью
java -XX:MaxRAMPercentage=90 -jar app.jar
# контейнер ограничен 1 GiB, приложение использует direct buffers и много потоков

Включить структурированные журналы сборщика мусора и события JFR, затем сопоставить паузы с задержками и размером живых данных. Ввести ограничение размера/времени жизни, слабые ключи при подходящем контракте или явное удаление. Задать размер кучи с запасом после измерения общей резидентной памяти и нативной памяти, включить Native Memory Tracking и проверить поведение под рабочей нагрузкой. Найти корни сборщика мусора и дерево доминаторов, затем связать цепочку ссылок с жизненным циклом компонента. Смотреть на объём живых объектов после сборки и скорость выделения памяти, а не только на общий объём созданных объектов.

Вопрос 9 из 30

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

# Минимальный пример
java -Xms8g -Xmx8g -Xlog:gc*:file=gc.log:time,uptime,level,tags -jar app.jar

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

Вопрос 10 из 30

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

// Минимальный пример
for (var row : rows) {
    var dto = new ResultDto(row.id(), transform(row.value()));
    sink.accept(dto);
}

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

Вопрос 11 из 30

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

for (var row : rows) {
    var dto = new ResultDto(row.id(), transform(row.value()));
    sink.accept(dto);
}

Редкая длинная полная сборка мусора может определять 99-й процентиль задержки при хорошем среднем времени ответа. Статическая Map без удаления удерживает ключи и значения после завершения запросов. Частое создание короткоживущих объектов передачи данных обычно не означает утечку, если после сборки молодой области память освобождается. Глубокая рекурсия исчерпывает стек и приводит к StackOverflowError независимо от объёма свободной памяти в куче. Список классов с большим поверхностным размером не обязательно указывает владельца удерживаемых объектов.

Вопрос 12 из 30

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

// Минимальный пример
class Registry {
    static final java.util.Map<String, byte[]> DATA = new java.util.HashMap<>();
    static void remember(String id, byte[] payload) { DATA.put(id, payload); }
}

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

Вопрос 13 из 30

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

Объекты обычно размещаются в куче, а кадры вызовов и локальные переменные каждого потока — в его стеке; JIT-компилятор может оптимизировать фактическое размещение. Причину паузы оценивают по журналам сборщика мусора, объёму живых объектов, скорости выделения памяти и целям выбранного сборщика, а не по одному среднему времени. В управляемой памяти утечка — это ненужные объекты, которые остаются достижимыми по цепочке сильных ссылок. Диагностика памяти требует воспроизводимой нагрузки, снимка кучи или данных JFR, а также сравнения доминаторов и удерживаемого размера. Большинство новых объектов быстро умирает; сборщики мусора с поколениями используют это свойство для дешёвой очистки молодой области.

Вопрос 14 из 30

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

// Фрагмент на ревью
for (var row : rows) {
    var dto = new ResultDto(row.id(), transform(row.value()));
    sink.accept(dto);
}

Заменить неограниченную рекурсию итерацией или ограничить глубину входа. Смотреть на объём живых объектов после сборки и скорость выделения памяти, а не только на общий объём созданных объектов. Найти корни сборщика мусора и дерево доминаторов, затем связать цепочку ссылок с жизненным циклом компонента. Задать размер кучи с запасом после измерения общей резидентной памяти и нативной памяти, включить Native Memory Tracking и проверить поведение под рабочей нагрузкой. Включить структурированные журналы сборщика мусора и события JFR, затем сопоставить паузы с задержками и размером живых данных.

Вопрос 15 из 30

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

jcmd <pid> GC.heap_dump /secure/path/heap.hprof
# затем анализ дерева доминаторов и путей к корням сборщика мусора

Редкая длинная полная сборка мусора может определять 99-й процентиль задержки при хорошем среднем времени ответа. Куча, занимающая 90% лимита в 1 ГиБ, оставляет мало места для метаданных классов, прямых буферов, стеков и нативной памяти; контейнер может завершить процесс из-за нехватки памяти. Глубокая рекурсия исчерпывает стек и приводит к StackOverflowError независимо от объёма свободной памяти в куче. Статическая Map без удаления удерживает ключи и значения после завершения запросов. Список классов с большим поверхностным размером не обязательно указывает владельца удерживаемых объектов.

Вопрос 16 из 30

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

// Фрагмент на ревью
static long sum(long n) {
    return n == 0 ? 0 : n + sum(n - 1);
}
System.out.println(sum(10_000_000));

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

Вопрос 17 из 30

Что произойдёт с кодом по теме «Куча и стек» в разделе «Память JVM и сборка мусора»?

static long sum(long n) {
    return n == 0 ? 0 : n + sum(n - 1);
}
System.out.println(sum(10_000_000));

Глубокая рекурсия исчерпывает стек и приводит к StackOverflowError независимо от объёма свободной памяти в куче. Запуск миллиона тяжёлых вычислений в отдельных виртуальных потоках создаёт конкуренцию за процессор и память, а не ускорение. Список классов с большим поверхностным размером не обязательно указывает владельца удерживаемых объектов. Глубокая рекурсия исчерпывает стек и приводит к OutOfMemoryError независимо от объёма свободной памяти в куче. Частое создание короткоживущих объектов передачи данных обычно не означает утечку, если после сборки молодой области память освобождается.

Вопрос 18 из 30

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

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

Вопрос 19 из 30

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

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

Вопрос 20 из 30

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

java -Xms8g -Xmx8g -Xlog:gc*:file=gc.log:time,uptime,level,tags -jar app.jar
# p50 ответа: 25 мс; p99: 1,9 с
# редкие скачки p99 совпадают с Pause Full длительностью 1,7–1,9 с

Редкая длинная полная сборка мусора может определять 98-й процентиль задержки при хорошем среднем времени ответа. Редкая длинная полная сборка мусора может определять 100-й процентиль задержки при хорошем среднем времени ответа. Статическая Map без удаления удерживает ключи и значения после завершения запросов. Куча, занимающая 90% лимита в 1 ГиБ, оставляет мало места для метаданных классов, прямых буферов, стеков и нативной памяти; контейнер может завершить процесс из-за нехватки памяти. Редкая длинная полная сборка мусора может определять 99-й процентиль задержки при хорошем среднем времени ответа.

Вопрос 21 из 30

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

Ключевые метрики — число активных и ожидающих виртуальных потоков, занятость потоков-носителей, очередь внешнего ресурса и хвостовые задержки. Объекты обычно размещаются в куче, а кадры вызовов и локальные переменные каждого потока — в его стеке; JIT-компилятор может оптимизировать фактическое размещение. Виртуальные потоки подходят для большого числа задач, которые преимущественно ждут ввод-вывод; вычислительную работу всё равно ограничивает число доступных ядер. Виртуальный поток — обычный Thread для кода приложения, который JVM планирует поверх небольшого числа потоков-носителей. Большинство новых объектов быстро умирает; сборщики мусора с поколениями используют это свойство для дешёвой очистки молодой области.

Вопрос 22 из 30

Что следует изменить в разделе «Память JVM и сборка мусора», чтобы сохранить замысел и соблюсти контракт «Утечки ссылок»?

// Фрагмент на ревью
class Registry {
    static final java.util.Map<String, byte[]> DATA = new java.util.HashMap<>();
    static void remember(String id, byte[] payload) { DATA.put(id, payload); }
}

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

Вопрос 23 из 30

Какое правило Java действует для темы «Тестирование и диагностика» в разделе «Память JVM и сборка мусора»?

Устойчивый сервис оставляет запас памяти вне кучи, контролирует скорость выделения объектов и не работает постоянно у предела после каждой сборки. Диагностика памяти не требует воспроизводимой нагрузки, снимка кучи или данных JFR, а также сравнения доминаторов и удерживаемого размера. Диагностика памяти требует воспроизводимой нагрузки, снимка кучи или данных JFR, а также сравнения доминаторов и удерживаемого размера. Причину паузы оценивают по журналам сборщика мусора, объёму живых объектов, скорости выделения памяти и целям выбранного сборщика, а не по одному среднему времени. Объекты обычно размещаются в куче, а кадры вызовов и локальные переменные каждого потока — в его стеке; JIT-компилятор может оптимизировать фактическое размещение.

Вопрос 24 из 30

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

# Фрагмент на ревью
jcmd <pid> GC.heap_dump /secure/path/heap.hprof
# затем анализ дерева доминаторов и путей к корням сборщика мусора

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

Вопрос 25 из 30

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

# Минимальный пример
java -XX:MaxRAMPercentage=90 -jar app.jar
# контейнер ограничен 1 GiB, приложение использует direct buffers и много потоков

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

Вопрос 26 из 30

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

# Минимальный пример
jcmd <pid> GC.heap_dump /secure/path/heap.hprof
# затем анализ дерева доминаторов и путей к корням сборщика мусора

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

Вопрос 27 из 30

Что следует изменить в разделе «Память JVM и сборка мусора», чтобы сохранить замысел и соблюсти контракт «Паузы сборщика мусора»?

# Фрагмент на ревью
java -Xms8g -Xmx8g -Xlog:gc*:file=gc.log:time,uptime,level,tags -jar app.jar

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

Вопрос 28 из 30

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

class Registry {
    static final java.util.Map<String, byte[]> DATA = new java.util.HashMap<>();
    static void remember(String id, byte[] payload) { DATA.put(id, payload); }
}

Статическая Map без удаления удерживает ключи и значения после завершения запросов. Статическая Map<Class<?>, Metadata> в родительском загрузчике может удерживать выгруженный загрузчик плагина. Статическая FlatMap без удаления удерживает ключи и значения после завершения запросов. Частое создание короткоживущих объектов передачи данных обычно не означает утечку, если после сборки молодой области память освобождается. Список классов с большим поверхностным размером не обязательно указывает владельца удерживаемых объектов.