Загрузка классов в JVM

Фазы и делегирование родителю

Попросил свой загрузчик выдать java.lang.String. Получил класс, у которого getClassLoader() вернул null, а сравнение с String.class по == дало true - тот самый, системный. Потом попробовал определить собственный класс с именем java.lang.Evil и получил SecurityException: Prohibited package name: java.lang.

Так работает делегирование родителю: загрузчик сперва спрашивает родителя и грузит сам, только если тот не смог. Наверху цепочки bootstrap с ядром JDK, под ним platform, под ним application - тот, что грузит твой classpath, то есть список папок и jar-файлов, где JVM ищет классы приложения. Подсунуть свой java.lang.String не выйдет с двух сторон: сначала не даст делегирование, а если обойти его - не даст проверка имени пакета.

Сам класс грузится лениво, при первом использовании, и проходит три фазы. Loading - байты .class-файла превращаются в объект Class. Linking - verify проверяет байткод (инструкции для виртуальной машины, в которые javac перевёл твой исходник) на согласованность, prepare раздаёт статическим полям значения по умолчанию, resolve разрешает ссылки на другие классы. Initialization - отрабатывают статические блоки, строго один раз и под локом. Тяжёлая логика в статическом блоке взорвётся в непредсказуемый момент: тогда, когда до класса впервые дотянутся.

делегирование родителю

родительский загрузчик пробует первым

initialization

исполнение статических блоков, один раз на класс

Класс - это имя ПЛЮС загрузчик

Тот же замер в цифрах: сравнение классов по == дало false, проверка isInstance для чужого объекта - false, а статическое поле counter я выставил в 5 через первый класс и прочитал 0 через второй. Одно имя, один и тот же файл, две независимые сущности со своей статикой.

JVM идентифицирует класс парой «полное имя плюс загрузчик». Отсюда и вся мистика. Хорошая новость: с Java 9 сообщение об ошибке само называет обоих виновников - loader 'app-A' @677327b6 против loader 'app'. Увидел одинаковые имена и разные загрузчики в скобках - диагноз готов, дальше ищешь, откуда взялась вторая копия библиотеки.

Родом это обычно из инверсии делегирования: Tomcat и плагинные системы сознательно грузят сначала своё, потом родительское, чтобы вебапп нёс собственные версии библиотек. Цена - вот такие классы-двойники и утечки при редеплое.

Class<?> c1 = new Loader("A").loadClass("User");
Class<?> c2 = new Loader("B").loadClass("User");

c1 == c2;                                        // false
c2.isInstance(c1.getDeclaredConstructor().newInstance()); // false
// counter через A = 5, через B = 0 - статика раздельная

идентичность класса

полное имя плюс загрузчик, а не одно имя

Утечка загрузчика при редеплое, в цифрах

Загрузил User.class тремя тысячами разных загрузчиков и оставил по одному живому объекту от каждого. Было 722 класса в памяти и 635 КиБ Metaspace - стало 3982 класса и 5607 КиБ. Потом отпустил ссылки и позвал сборку: выгружено 3000 классов, Metaspace откатился к 1382 КиБ.

Считаем: 3260 лишних классов съели около 5 МиБ, примерно по полтора килобайта на класс. Немного. Но это ОДИН класс на загрузчик, а реальный вебапп несёт тысячи классов, и каждый редеплой добавляет полный комплект.

Ключевое во втором замере: классы выгрузились, как только загрузчик стал недостижим. Загрузчик держит все свои классы, а каждый класс держит свой загрузчик, поэтому одна живая ссылка снаружи - из пула потоков, ThreadLocal, реестра драйверов, статики сервера - удерживает весь комплект целиком. Metaspace растёт от редеплоя к редеплою, и это уже утечка, а не «нормальный рост».

утечка загрузчика

одна внешняя ссылка удерживает все классы вебаппа

Ошибки-близнецы: читаем точные тексты

Сделал класс, у которого статический блок падает, и обратился к нему трижды. Первое обращение: ExceptionInInitializerError, причина - NumberFormatException. Второе и третье: NoClassDefFoundError: Could not initialize class Config.

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

Развилка простая. ClassNotFoundException - checked-исключение, то есть такое, которое компилятор заставляет либо ловить, либо объявлять в сигнатуре. Класс просили по имени через Class.forName или loadClass и не нашли: типично для рефлексии (обращения к классам по строковому имени во время работы программы), конфигов и забытого драйвера. NoClassDefFoundError - класс был при компиляции и пропал в рантайме либо умер на инициализации. NoSuchMethodError и IncompatibleClassChangeError - бинарная несовместимость: собрано против одной версии библиотеки, в рантайме другая.

static class Config {
    static final int PORT;
    static { PORT = Integer.parseInt(System.getenv("PORT")); }  // упало
}

// обращение 1: ExceptionInInitializerError, cause = NumberFormatException
// обращение 2: NoClassDefFoundError: Could not initialize class Config
// обращение 3: NoClassDefFoundError: Could not initialize class Config

ExceptionInInitializerError

упал статический блок, класс мёртв до рестарта

NoSuchMethodError

в рантайме другая версия библиотеки, чем при сборке

Как отвечать: «Чем ClassNotFoundException отличается от NoClassDefFoundError?»

ClassNotFoundException - checked-исключение при явной загрузке по имени: Class.forName или loadClass не нашли класс в classpath, типично для рефлексии и подключаемых драйверов. NoClassDefFoundError - ошибка самой JVM: класс был при компиляции, а в рантайме его нет. И у неё есть коварный второй сценарий, который я проверял руками: класс на месте, но его статическая инициализация упала. Первое обращение даёт ExceptionInInitializerError с настоящей причиной, а второе и все следующие - уже NoClassDefFoundError со словами «Could not initialize class». Поэтому при таком падении я ищу в логах первую ошибку, а не последнюю. Если же летит NoSuchMethodError, то это про другое: собрано против одной версии библиотеки, а в classpath оказалась другая.

Почему это сильный ответ: различие проведено по механике - явный запрос против ссылки из кода, назван неочевидный сценарий с упавшим статическим блоком и дан диагностический приём вместо пересказа определений.

На чём валят

• −«X не кастится к X - это глюк JVM». Это две копии класса из разных загрузчиков; имена загрузчиков написаны прямо в сообщении.
• −Списать NoClassDefFoundError на classpath, когда упал статический инициализатор. Смотри первую ошибку в логах, там настоящая причина.
• −Тяжёлая логика или обращение к сети в статическом блоке. Класс взорвётся при первом касании, а момент непредсказуем.
• −Две версии библиотеки в зависимостях. Локально работает, в проде NoSuchMethodError - победила другая версия.
• −Глобальная ссылка на объект вебаппа из пула или ThreadLocal. Редеплой не выгрузит старый загрузчик, и Metaspace будет расти каждый раз.