Предскажите последствия повторного обращения к классу после сбоя его статической инициализации. Первый и вт...

public class Main {
    static class Config {
        static {
            System.out.print("I");
            throw new RuntimeException("init");
        }
        static int VALUE = 1;
    }

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

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

При первом обращении JVM запускает инициализацию Config, печатает I, после чего оборачивает RuntimeException в ExceptionInInitializerError. Класс помечается как неуспешно инициализированный. При втором обращении повторная инициализация не выполняется: возникает NoClassDefFoundError.

Итоговый вывод будет таким:

IExceptionInInitializerError NoClassDefFoundError 

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

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

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

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

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

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

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

При активном использовании Config.VALUE JVM проверяет состояние класса и запускает его инициализацию. Блок печатает I, затем выбрасывает RuntimeException. Поскольку это не Error, JVM представляет сбой вызывающему коду как ExceptionInInitializerError, сохраняя исходное исключение как причину.

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

Инициализация не запускается повторно даже при обращении из другого потока. Механизм также синхронизирует процесс инициализации, поэтому два потока не выполняют статический блок одновременно.

Важно отличать NoClassDefFoundError в этом сценарии от отсутствия class-файла. Здесь класс физически найден, но JVM не может использовать его из-за ранее проваленной инициализации.

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

    private static String load() {
        throw new IllegalStateException("invalid configuration");
    }
}

class App {
    public static void main(String[] args) {
        try {
            System.out.println(Settings.URL);
        } catch (ExceptionInInitializerError e) {
            System.out.println(e.getCause().getMessage());
        }
    }
}

Перехватывать Throwable без необходимости не следует: ExceptionInInitializerError и особенно NoClassDefFoundError обычно означают неисправимое состояние класса, а не обычную бизнес-ошибку.

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

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

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

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

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

1. Всегда ли первый сбой превращается именно в ExceptionInInitializerError?

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

2. Запускает ли Class.forName статическую инициализацию?

Обычный вызов Class.forName(name) загружает класс и инициирует его инициализацию. Перегруженный вариант Class.forName(name, false, loader) загружает класс без инициализации. Это позволяет заранее загрузить метаданные, не запуская статические блоки.

3. Можно ли повторить инициализацию после ошибки?

Для того же класса и того же загрузчика классов — нет: класс остаётся ошибочным. Теоретически другой загрузчик может загрузить отдельную копию класса и инициировать её независимо, но это уже другой тип Class с отдельными статическими полями и собственным состоянием; применять такой подход как обычный механизм повторной попытки не следует.