JVM и память

Что означает целевой бюджет паузы у G1 и почему его превышение не доказывает неисправность JVM?

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

Ситуация: два потока зависли во взаимных статических инициализаторах разных классов. Как механизм инициализации классов приводит к deadlock?

Два объекта ссылаются только друг на друга, но ни одна ссылка из корней JVM до них не доходит. Объясните, сможет ли сборщик мусора освободить их.

Представьте, что Resource передаёт нативному коду внутреннее состояние, а очистку выполняет Cleaner. Зачем в конце метода нужна Reference.reachabilityFence(this)?

import java.lang.ref.Reference;
import java.lang.ref.Cleaner;

final class Resource implements AutoCloseable {
    static final Cleaner CLEANER = Cleaner.create();
    static final class State implements Runnable {
        public void run() { System.out.println("cleanup"); }
    }

    private final State state = new State();
    private final Cleaner.Cleanable cleanable = CLEANER.register(this, state);

    void use() {
        nativeCall(state);
        Reference.reachabilityFence(this);
    }

    static void nativeCall(State state) { /* длительный JNI-вызов */ }
    public void close() { cleanable.clean(); }
}

Как механизм Class Data Sharing сокращает время запуска Java-приложения при повторном использовании одного набора классов?

Каким образом JIT-компилированный метод сохраняет возможность построения корректного stack trace?

У Java-процесса свободен heap, но создание нового platform thread завершается OutOfMemoryError. Какой ресурс JVM и ОС следует искать?

После завершённых циклов GC базовый объём занятой Java-памяти растёт от цикла к циклу. Какой вывод нужно проверить первым?

Живёт ли интернированная строка до завершения JVM?

Горячий метод после JIT-компиляции стал медленнее из-за чрезмерного встраивания вызовов. Какой механизм объясняет такой парадокс?

Рассмотрите молодую сборку, после которой в heap ещё много свободной памяти. Почему она всё равно может завершиться Full GC?

Нативный модуль сохраняет ссылку на Java-объект после завершения обычного вызова. Почему сборщик мусора может не освободить этот объект?

В пуле потоков после обработки множества задач растёт heap. Определите, какая ссылка в этом коде может удерживать большие массивы после завершения задач.

import java.util.concurrent.*;

public class Demo {
    static void handle() {
        ThreadLocal<byte[]> local = new ThreadLocal<>();
        local.set(new byte[10_000_000]);
    }

    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newFixedThreadPool(1);
        for (int i = 0; i < 1_000; i++) {
            pool.submit(Demo::handle).get();
        }
        pool.shutdown();
    }
}

Как расширение адресного пространства heap может увеличить размер объектов в 64-битной JVM?

Как диагностировать рост нативной памяти JVM, если heap dump не показывает виновника?

Сервис после увеличения максимального heap стал заметно потреблять больше памяти при том же числе объектов. Какой механизм JVM может объяснить этот эффект?

Объект стал недостижимым, но пережил первую сборку мусора. Как механизм финализации объясняет его временное сохранение?

За счёт чего ZGC перемещает объекты почти без длительной остановки приложения?

Что нельзя заключить из одного heap dump о причинах высокого allocation rate в Java-приложении?