Инициализация bean-а

1. Роль init-фазы и конструктора

Мы уже отделили сам факт создания объекта от момента, когда bean действительно готов к работе. Теперь надо понять, чем контейнер заполняет этот зазор.

Если вы только-только подружились с DI, очень хочется сказать: «Ну я же получаю зависимости в конструкторе. Значит, конструктор — идеальное место, чтобы сразу всё подготовить». Логика понятная, но в Spring-мире она часто приводит к коду, который сложно читать, тестировать и поддерживать. Init-фаза — это способ сделать подготовку объекта явной и управляемой контейнером, а не спрятанной в конструкторе.

Конструктор в DI-friendly коде хорошо выполняет роль «контракта»: он говорит, без чего объект жить не может. Он должен быть быстрым и предсказуемым, как хорошее утро разработчика: открыл ноутбук — и ничего не горит. А вот подготовка внутреннего состояния — это часто отдельный шаг. Например, объект может захотеть построить внутренний индекс, прогреть кэш, проверить что-то в своих зависимостях или подготовить рабочую папку для вывода отчётов. Это уже ближе к «перед стартом убедиться, что шнур питания воткнут», чем к простому созданию объекта.

Полезно держать в голове простую границу: конструктор — про получение обязательных зависимостей, init-фаза — про приведение объекта в рабочее состояние. Это не «официальный закон физики Spring», а скорее инженерная привычка, которая резко снижает количество «странных» багов на старте.

Небольшая табличка для ориентации:

Чтобы не казалось, что это чистая философия, давайте сделаем простейшее наблюдение: конструктор вызывается всегда, когда вы делаете new, а init-фаза вызывается только когда объект создан контейнером как bean. И вот тут у Spring появляется суперсила: он может гарантировать, что init-логика вызовется ровно в нужный момент, а не «где-то забыли — и оно не случилось».

2. @PostConstruct

@PostConstruct — это почти идеальный старт для новичка. Во‑первых, он читается как человеческая фраза: «после создания — сделай вот это». Во‑вторых, это не чисто Spring-аннотация, а часть Jakarta-аннотаций (исторически JSR-250), то есть выглядит более нейтрально. В‑третьих, в классе появляется очевидное место, где лежит его подготовка, а не «магия в конфиге по строковому имени».

Для @PostConstruct обычно достаточно помнить три вещи: метод должен быть без параметров, он должен быть void, и он должен описывать подготовку объекта, а не запуск основного сценария приложения. Если метод бросит исключение, Spring, как правило, уронит старт контекста, что для проверок и fail-fast поведения обычно очень полезно: лучше упасть сразу, чем «поработать чуть-чуть и умереть в пятницу вечером».

Покажем это на упрощённом NotificationTemplateCatalog — каталоге шаблонов уведомлений для ContextFlow. Пока не усложняем: шаблоны будут просто лежать в памяти (без ресурсов и файлов).

import jakarta.annotation.PostConstruct;
import org.springframework.stereotype.Component;

import java.util.concurrent.ConcurrentHashMap;

@Component
class NotificationTemplateCatalog {

    // Потокобезопасное хранилище шаблонов, доступное после init-фазы.
    private final ConcurrentHashMap<String, String> templates = new ConcurrentHashMap<>();

    @PostConstruct
    void init() {
        // Init-фаза: один раз заполняем каталог при старте контекста.
        templates.put("order-created", "Order %s created");
        templates.put("order-cancelled", "Order %s cancelled");
    }

    String template(String key) {
        // После старта контекста ожидаем, что нужные ключи уже загружены.
        return templates.get(key);
    }
}

Смысл такой: конструктор тут вообще не нужен (у нас пока нет внешних зависимостей), а вот init-фаза — да. Мы один раз заполняем каталог, и дальше он работает быстро и предсказуемо.

Теперь посмотрим, как это использует сервис, который формирует текст уведомления. Важно: сервис не обязан знать, когда заполняется каталог. Он получает уже «готовый» объект.

import org.springframework.stereotype.Service;

@Service
class NotificationDispatchService {
    private final NotificationTemplateCatalog catalog;

    NotificationDispatchService(NotificationTemplateCatalog catalog) {
        // Зависимость получаем через DI (constructor injection).
        this.catalog = catalog;
    }

    String buildCreatedText(String orderId) {
        // Предполагаем, что init уже заполнил ключ "order-created".
        return catalog.template("order-created").formatted(orderId);
    }
}

Если catalog.template("order-created") вернёт null, вы очень быстро почувствуете боль в рантайме. Поэтому часто в @PostConstruct делают маленькую валидацию, чтобы упасть на старте «понятно и честно».

import jakarta.annotation.PostConstruct;

class CatalogValidation {
    @PostConstruct
    void validate() {
        // Демонстрация fail-fast: если инициализация критична — падаем на старте контекста.
        throw new IllegalStateException("Example: init validation failed");
    }
}

Этот пример специально «плохой», чтобы подчеркнуть механику: init-фаза — нормальное место, чтобы зафиксировать «без этого мой bean не может работать».

Чтобы @PostConstruct работал, аннотация должна быть доступна на classpath. В нашем курсе это предусмотрено, но в реальной жизни вы иногда ловите ситуацию «аннотацию поставил, а метод не вызвался», потому что зависимость не добавили.

Мини-напоминание в стиле «одна строчка, которая экономит час»:

dependencies {
    // Нужна, чтобы аннотация @PostConstruct была доступна на classpath.
    implementation("jakarta.annotation:jakarta.annotation-api")
}

Нам здесь важен прикладной факт: если bean — container-managed, то @PostConstruct — официальный способ сказать контейнеру «у меня есть фаза подготовки». За кулисами это тоже обслуживает инфраструктура контейнера, но для текущей задачи достаточно самого контракта.

3. InitializingBean: инициализация через интерфейс

Интерфейс InitializingBean — это «олдскульный, но честный» путь. Он работает в чистом Spring без дополнительных аннотаций: вы реализуете метод afterPropertiesSet(), и контейнер вызывает его после того, как зависимости уже внедрены. По духу это очень похоже на @PostConstruct, только вместо аннотации — интерфейс.

У новичка тут часто возникает вопрос: «А зачем вообще нужен интерфейс, если есть аннотация?» Ответ простой: иногда вам важнее явная зависимость от Spring, чем нейтральность. Особенно это бывает в инфраструктурных beans, где никто не пытается притворяться, что класс «фреймворк-агностичный». Но для бизнес-слоя и большинства прикладных компонентов это всё же лишняя связность: класс начинает прямо зависеть от Spring API.

Сделаем небольшой пример bean-а, который просто отмечает «контекст готов» и печатает сообщение. Это не бизнес-логика, это чистая диагностика/инфраструктура — как раз тот случай, где Spring-зависимость не пугает.

import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Component;

@Component
class ContextFlowStartupMarker implements InitializingBean {
    @Override
    public void afterPropertiesSet() {
        // Метод вызовет контейнер после внедрения зависимостей (и до использования bean-а).
        System.out.println("ContextFlow startup marker: READY");
    }
}

Метод называется «afterPropertiesSet» исторически, потому что Spring когда-то активно использовал setter injection. Мы с вами предпочитаем constructor injection, но метод всё равно означает понятную вещь: «после того как контейнер всё внедрил и настроил — сделай финальную подготовку».

Здесь есть один методический риск: новичок видит интерфейс и начинает думать, что это «правильный стандарт». На практике чаще teaching default — @PostConstruct, потому что он проще читается и меньше привязывает код к Spring. InitializingBean полезно знать именно как часть общей карты: вы встретите его в легаси-коде и в инфраструктурных штуках, и важно не пугаться.

4. initMethod в @Bean

Теперь третий способ — очень практичный. Иногда класс наш, но мы хотим, чтобы он оставался максимально «обычной Java-штукой» без аннотаций. Иногда класс вообще не наш: библиотечный, legacy или такой, где мы не имеем права менять код. А ещё бывает, что bean создаётся через @Bean-метод, и нам удобнее описать lifecycle прямо в конфигурации, не трогая сам класс.

Для этого есть параметр initMethod у @Bean. Контейнер после создания bean-а вызовет метод с указанным именем. Да, там строка (и да, IDE может не поймать ошибку при переименовании, если вы неаккуратны), но для инфраструктурных вещей это часто оправдано.

Давайте сделаем ReportOutputManager — объект, который отвечает за подготовку директории для отчётов. По правилам проекта артефакты должны идти в build/reports, так что мы и подготовим build/reports.

import java.nio.file.Files;
import java.nio.file.Path;

class ReportOutputManager {
    private final Path dir;

    ReportOutputManager(Path dir) {
        // Зависимость (путь) задаём снаружи — объект остаётся простым POJO.
        this.dir = dir;
    }

    void prepare() {
        // Init-логика: убедиться, что директория существует.
        try {
            Files.createDirectories(dir);
        } catch (Exception e) {
            // Если директорию создать нельзя — лучше упасть на старте с понятной причиной.
            throw new IllegalStateException(e);
        }
    }

    Path dir() {
        return dir;
    }
}

Класс абсолютно POJO: никаких Spring-интерфейсов, никаких аннотаций. Теперь опишем init-фазу в конфигурации.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.nio.file.Path;

@Configuration
class ReportingConfig {
    @Bean(initMethod = "prepare")
    ReportOutputManager reportOutputManager() {
        // Контейнер сам вызовет prepare() после создания bean-а.
        return new ReportOutputManager(Path.of("build/reports"));
    }
}

Фишка в том, что prepare() вызовет контейнер. Это значит, что любой сервис, который получил ReportOutputManager через DI, может считать: «если контекст стартовал, директория уже создана». И это ровно тот вид гарантий, из-за которых Spring и придуман: меньше ручного протокола между объектами, больше предсказуемости.

Небольшой пример использования — пусть даже просто для демонстрации того, что сервис больше не обязан “дёргать prepare() сам”.

import org.springframework.stereotype.Service;

@Service
class ReportingService {
    private final ReportOutputManager output;

    ReportingService(ReportOutputManager output) {
        // Получаем уже "подготовленный" bean (если контекст успешно стартовал).
        this.output = output;
    }

    void printOutputDir() {
        // Демонстрация: директория должна быть готова к использованию.
        System.out.println(output.dir()); // build/reports
    }
}

Важно не путать initMethod с «ну я вызову prepare() прямо внутри @Bean-метода». Вызвать вы, конечно, можете, но тогда это превратится в ручной протокол внутри конфигурации. Гораздо честнее (и проще читать), когда вы явно говорите контейнеру: «это lifecycle-часть, вызывай сам».

5. Выбор способа инициализации

После трёх вариантов хочется спросить: «Так какой правильный?» И это хороший вопрос, потому что у новичка часто включается режим “соберу комбо”: @PostConstruct + InitializingBean + initMethod — на всякий случай, чтобы точно сработало. Но Spring — не микроволновка: «дважды разогреть» не значит «вдвое вкуснее». Скорее наоборот: вы получите неясный порядок вызовов и непредсказуемость.

Проще всего выбрать так: если это ваш класс и инициализация является частью его логики — берите @PostConstruct. Если вы делаете инфраструктурный bean и вам норм, что он явно зависит от Spring, — InitializingBean тоже подходит. Если класс трогать нельзя или не хочется — initMethod в @Bean. Это решение не про “модно/немодно”, а про читаемость и архитектурную цену.

Вот компактная таблица, которую удобно держать перед глазами:

И ещё один важный критерий: хороший init-метод должен быть маленьким и скучным. Скучным — в хорошем смысле. Если init-метод вызывает пять сервисов, отправляет уведомления, считает отчёты и делает сетевые запросы, то это уже не «инициализация», а «тайный запуск бизнес-процесса без спроса». Контейнер вам за такое не обязан, и коллеги тоже.

6. Порядок вызовов init-колбэков

Иногда полезно один раз увидеть, что будет, если “смешать всё”. Мы сделаем это осознанно, как в лаборатории: в жизни так писать не нужно, но для понимания порядка вызовов — очень наглядно. Дальше вы сможете спокойно читать чужой код и понимать, почему у него «лишние логи» и «всё вызывается три раза».

Вот bean, который использует сразу все варианты:

import jakarta.annotation.PostConstruct;
import org.springframework.beans.factory.InitializingBean;

class InitOrderDemoBean implements InitializingBean {

    InitOrderDemoBean() {
        // 1) Конструктор всегда вызывается при создании объекта.
        System.out.println("1) constructor");
    }

    @PostConstruct
    void pc() {
        // 2) Вызывается контейнером после создания bean-а и внедрения зависимостей.
        System.out.println("2) @PostConstruct");
    }

    @Override
    public void afterPropertiesSet() {
        // 3) Колбэк через Spring-интерфейс InitializingBean.
        System.out.println("3) afterPropertiesSet");
    }

    void initMethod() {
        // 4) Колбэк, указанный в @Bean(initMethod = "...").
        System.out.println("4) initMethod");
    }
}

Подключим его через @Bean(initMethod = "initMethod"):

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
class DemoConfig {
    @Bean(initMethod = "initMethod")
    InitOrderDemoBean demo() {
        // Важно: initMethod() будет вызван контейнером, а не здесь вручную.
        return new InitOrderDemoBean();
    }
}

И запустим минимальный контекст:

import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class App {
    public static void main(String[] args) {
        try (var ctx = new AnnotationConfigApplicationContext(DemoConfig.class)) {
            // Получаем bean — к этому моменту init-фаза уже выполнена.
            ctx.getBean(InitOrderDemoBean.class);
        }
    }
}

Если вы запустите это, то увидите в консоли порядок, который обычно важно помнить концептуально: сначала создаётся объект (конструктор), затем вызываются init-колбэки, и только после этого bean считается готовым.

Главный вывод из демо простой: контейнер реально умеет вызвать все эти вещи, но это не значит, что надо “дублировать защиту”. Выберите один способ на bean, и ваши будущие вы сами скажут вам спасибо (и перестанут писать в дневнике “почему всё ломается по утрам”).

7. Примеры в ContextFlow

Теперь вернёмся к нашему проекту ContextFlow. У нас есть два компонента, которые очень естественно демонстрируют init-фазу. Первый — NotificationTemplateCatalog: он должен подготовить внутренний кэш/каталог шаблонов. Второй — ReportOutputManager: он должен подготовить место, куда будет писать отчёты.

Здесь важно заметить, что мы не «добавляем init ради init». Мы решаем прикладную проблему: хотим, чтобы сервисы не занимались чужой подготовкой и не носили в себе протокол “если не готово — подготовь”. В хорошей архитектуре NotificationDispatchService занимается уведомлениями, а не загрузкой шаблонов; ReportingService занимается отчётами, а не созданием директорий.

Поэтому выбранные подходы выглядят естественно: для NotificationTemplateCatalog — @PostConstruct (наш класс, логика подготовки принадлежит ему), а для ReportOutputManager — initMethod (класс можно держать POJO, а lifecycle описать в конфигурации).

Если вы захотите позже поменять реализацию, например сделать другой ReportOutputManager для другого режима, то контейнерная модель останется такой же: “создай, внедри, подготовь, только потом отдавай в use-case”. И это как раз та mental model, которую мы строим сегодня.

8. Типичные ошибки при инициализации beans

Ошибка №1: превращать init-фазу в «скрытый main».
Иногда разработчик добавляет @PostConstruct и начинает запускать там бизнес-сценарии: «сгенерирую отчёт при старте», «отправлю всем уведомление, что сервис поднялся», «создам тестовый заказ». В результате приложение становится непредсказуемым: просто старт контекста уже делает побочные эффекты. Init-логика должна быть подготовкой и проверкой, а не бизнес-оркестрацией.

Ошибка №2: делать тяжёлую подготовку в конструкторе “потому что так проще”.
Конструктор вызывается при любом new, в том числе в unit-тестах и в местах, где вы не ожидали реального запуска подготовки. Если внутри конструктора у вас IO, создание директорий или прогрев больших структур, вы получаете тяжёлый и плохо контролируемый объект. Гораздо лучше держать конструктор быстрым, а подготовку — в init-фазе, где контейнер управляет моментом вызова.

Ошибка №3: смешивать @PostConstruct, InitializingBean и initMethod на одном и том же bean-е.
С точки зрения Spring это не “ошибка компиляции”, а допустимое поведение: контейнер вызовет всё, что вы попросили. Но для человека, который читает код, это почти всегда путаница. Вы не получаете “больше надёжности”, вы получаете “больше мест, где что-то может сломаться” и “больше вопросов, почему лог печатается три раза”.

Ошибка №4: ожидать, что init вызовется у объекта, созданного вручную через new.
Это классическая ловушка при тестировании или при временных “ручных” инстансах. Если вы создаёте объект руками, контейнер его lifecycle не обслуживает: @PostConstruct не вызовется, afterPropertiesSet() не вызовется, initMethod тем более не вызовется. Либо поднимайте контекст, либо вызывайте подготовку явно, либо проектируйте класс так, чтобы он мог работать без контейнерной магии (но тогда, возможно, init вам и не нужен).

Ошибка №5: “проглатывать” исключения в init и делать вид, что всё нормально.
Иногда пишут try/catch в init-методе и в catch просто печатают “ой”. Это превращает проблему конфигурации в баг рантайма, который всплывёт позже и в более странном месте. Если инициализация критична (директория не создалась, обязательный шаблон не загрузился), лучше упасть на старте с понятным исключением.