Краткий ответ

При первом активном обращении JVM выполняет статическую инициализацию класса. Если она завершается обычным исключением, не являющимся Error, наружу обычно выбрасывается ExceptionInInitializerError; если причиной уже был Error, он может быть передан без такой обёртки. После этого класс помечается как находящийся в ошибочном состоянии, поэтому повторное обращение к нему в том же загрузчике классов приводит к NoClassDefFoundError, а не к повторному запуску инициализации.

Исторический контекст

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

Одновременно JVM должна предотвратить повторные попытки инициализации после частично выполненного кода. Иначе статическое состояние могло бы оказаться непредсказуемым, а побочные эффекты инициализации — выполненными несколько раз.

Постановка проблемы

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

Если не различать первый сбой и последующие обращения, можно ошибочно ожидать повторной попытки или искать исходную причину только в NoClassDefFoundError. На практике последующая ошибка сообщает прежде всего о том, что JVM уже признала класс непригодным для инициализации; исходная причина относится к первой попытке.

Подробное решение

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

После завершения с ошибкой класс получает состояние erroneous. Все последующие попытки инициализировать его через тот же ClassLoader завершаются NoClassDefFoundError. JVM не запускает статические инициализаторы заново.

Минимальный пример:

class Settings {
    static final String VALUE = load();

    static String load() {
        throw new IllegalStateException("broken config");
    }
}

public class Demo {
    public static void main(String[] args) {
        for (int i = 0; i < 2; i++) {
            try { System.out.println(Settings.VALUE); }
            catch (Throwable e) {
                System.out.println(e.getClass().getSimpleName());
            }
        }
    }
}

Первый проход обычно печатает ExceptionInInitializerError, второй — NoClassDefFoundError. Ловить Throwable в прикладном коде обычно не следует; здесь он используется только для демонстрации обоих результатов.

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

Ситуация из практики

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

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

Выбран был второй вариант: статическая часть содержала только неизменяемые безопасные значения, а загрузка конфигурации выполнялась при старте через отдельный компонент. Это сделало причину сбоя видимой, позволило контролировать политику повторов и исключило зависимость от состояния класса, уже помеченного JVM как ошибочного.

Что кандидаты часто упускают

Можно ли восстановить класс повторным вызовом его метода?

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

Всегда ли первым исключением будет именно ExceptionInInitializerError?

Нет. Если статическая инициализация выбросила Error, например OutOfMemoryError, JVM не обязана оборачивать его в ExceptionInInitializerError. Для обычных исключений, включая RuntimeException, применяется обёртка ExceptionInInitializerError; поэтому тип первого сбоя зависит от типа исходного выброшенного объекта.

Почему обработка второго NoClassDefFoundError не заменяет анализ первой ошибки?

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