JVM и память

При первом обращении к статическому полю класс неожиданно задерживает поток. Какой этап JVM выполняется перед использованием класса?

Что происходит с короткоживущим объектом, если JIT докажет, что он не покидает метод?

На G1 крупные массивы вызывают частые паузы при умеренной заполненности heap. Как размер одного объекта может привести к такому поведению?

Как JVM достигает глобальной остановки Java-потоков перед некоторыми операциями виртуальной машины?

Как JVM решает, какие методы переводить из интерпретируемого режима в машинный код?

Объясните, почему классы с одинаковым полным именем, загруженные двумя независимыми загрузчиками, считаются разными типами в JVM.

Сервис держит heap ниже установленного лимита, но RSS процесса постоянно растёт после обработки сетевых запросов. Какой механизм JVM может объяснить это расхождение?

В профиле heap после нескольких полных сборок остаются объекты результатов запросов, хотя локальные ссылки на них давно исчезли. Почему сборщик мусора всё ещё может считать эти объекты достижимыми?

Представьте, что после длительного прогрева первый вызов с новым типом Op внезапно выполняется медленнее. Объясните механизм JVM, который может вызвать такой всплеск задержки.

interface Op {
    int apply(int x);
}

final class Add implements Op {
    public int apply(int x) { return x + 1; }
}

final class Mul implements Op {
    public int apply(int x) { return x * 2; }
}

public class Main {
    static long run(Op op) {
        long sum = 0;
        for (int i = 0; i < 10_000_000; i++) sum += op.apply(i);
        return sum;
    }

    public static void main(String[] args) {
        Op add = new Add();
        for (int i = 0; i < 20; i++) run(add);
        System.out.println(run(new Mul()));
    }
}

При многократной перезагрузке Java-плагина классы остаются в Metaspace после сборки мусора. Какое условие нужно проверить первым, чтобы объяснить это поведение?