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

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

Сам факт завершения конструктора не делает ранее опубликованный объект безопасно видимым для других потоков. Нужен отдельный механизм безопасной публикации: блокировка, volatile-поле, потокобезопасный контейнер или другой гарантированный отношением happens-before способ.

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

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

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

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

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

Опасность состоит не только в чтении неправильного значения. Другой поток может навсегда не увидеть обновления, а одновременное чтение и запись обычного поля создаёт гонку данных. Синхронизация отдельных методов после публикации не исправляет сам факт раннего доступа к объекту.

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

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

class Registry {
    static Listener listener;

    static void register(Listener value) {
        listener = value;
    }
}

class Listener {
    private final String name;
    private int limit;

    Listener() {
        Registry.register(this);
        name = "ready";
        limit = 10;
    }
}

Если другой поток получит Registry.listener во время работы конструктора, он может увидеть name как null, а limit как 0. Поле final получает специальные гарантии видимости только при корректном завершении конструктора без утечки this; ранняя публикация подрывает ожидаемую безопасность такого дизайна.

Надёжный подход — сначала полностью создать объект, затем опубликовать ссылку через механизм с гарантией happens-before. Например, запись в volatile-поле, помещение в синхронизированную коллекцию или передача через уже корректно синхронизированный ExecutorService. Для неизменяемых объектов обычно достаточно завершить конструктор, не передавать this, и затем безопасно опубликовать готовый экземпляр.

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

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

Сервис регистрировал себя в общем диспетчере прямо из конструктора. Диспетчер сразу передавал зарегистрированный объект рабочему потоку, который иногда видел пустой список обработчиков и пропускал первые события.

Рассматривались три варианта. Добавление synchronized в методы сервиса защищало последующие вызовы, но не устраняло раннюю публикацию. Использование volatile для ссылки улучшало видимость готового состояния, однако не делало безопасной передачу ссылки до завершения конструктора. Перенос регистрации в фабричный метод устранял саму возможность доступа к недостроенному объекту.

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

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

Достаточно ли сделать поле со ссылкой на объект volatile, чтобы безопасно публиковать объект?

Да, запись полностью сконструированного объекта в volatile-поле и последующее чтение этого поля другим потоком создают необходимую видимость ранее выполненных записей. Но volatile не исправляет публикацию из конструктора: если ссылка записана до завершения инициализации, другой поток всё равно может получить недостроенный объект. Кроме того, volatile защищает видимость ссылки и предшествующих записей, но не делает составные изменения состояния атомарными.

Почему вызов переопределяемого метода из конструктора также считается формой утечки this?

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

Достаточно ли передать this в конструктор другого объекта, если тот пока не запускает поток?

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