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

Нет, NullPointerException при обращении к статическому полю через null-ссылку не возникает. Для статического поля Java использует класс, объявивший это поле, а значение ссылочного выражения отбрасывается после его вычисления.

Однако такой синтаксис вводит в заблуждение: статическое поле следует обращаться через имя класса, а не через переменную экземпляра.

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

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

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

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

Синтаксис доступа через переменную экземпляра визуально похож на обращение к обычному полю. Из-за этого разработчик может ожидать разыменование объекта и NullPointerException, хотя для статического поля объект фактически не используется.

Такая запись ухудшает читаемость и может скрывать ошибку проектирования. Если поле должно зависеть от состояния конкретного объекта, объявлять его статическим нельзя; если оно действительно общее, обращение через имя экземпляра создаёт ложное впечатление зависимости от объекта.

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

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

class Settings {
    static int timeout = 30;
}

Settings settings = null;
System.out.println(settings.timeout); // 30
System.out.println(Settings.timeout);  // 30

В обоих случаях читается одно и то же статическое поле Settings.timeout. Первый вариант допустим, но практически нежелателен: он маскирует статическую природу члена и может быть ошибочно принят за доступ к состоянию объекта.

Это правило относится к статическим членам в целом, включая статические методы: вызов через null-ссылку сам по себе не требует разыменования объекта. Но выбор статического метода определяется на этапе компиляции, поэтому такой вызов также не использует полиморфизм экземпляров.

Важно отличать это от обращения к нестатическому полю. Для нестатического поля объект необходим, поэтому попытка доступа через null действительно приводит к NullPointerException.

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

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

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

Выбран вариант с обращением через имя класса — Settings.timeout. Если же значение должно настраиваться отдельно для каждого экземпляра, поле делают нестатическим и явно обеспечивают создание либо проверку объекта. Это устраняет двусмысленность и делает ошибку с null явной.

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

1. Может ли обращение через null всё же вызвать побочный эффект?

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

2. Всегда ли при таком доступе выполняется инициализация класса?

Не обязательно. Доступ к статическому полю обычно может инициировать инициализацию класса, если она ещё не выполнена. Но статические константные переменные, являющиеся compile-time-константами, могут использоваться без инициализации класса, поскольку их значение встраивается компилятором.

3. Почему обращение через переменную экземпляра особенно опасно при наследовании?

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