Представьте, что Resource передаёт нативному коду внутреннее состояние, а очистку выполняет Cleaner. Зачем ...

import java.lang.ref.Reference;
import java.lang.ref.Cleaner;

final class Resource implements AutoCloseable {
    static final Cleaner CLEANER = Cleaner.create();
    static final class State implements Runnable {
        public void run() { System.out.println("cleanup"); }
    }

    private final State state = new State();
    private final Cleaner.Cleanable cleanable = CLEANER.register(this, state);

    void use() {
        nativeCall(state);
        Reference.reachabilityFence(this);
    }

    static void nativeCall(State state) { /* длительный JNI-вызов */ }
    public void close() { cleanable.clean(); }
}

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

Reference.reachabilityFence(this) не даёт сборщику мусора считать this недостижимым раньше указанной точки. Это важно, если JIT видит, что после последнего обычного обращения объект больше не нужен Java-коду, хотя нативная операция ещё использует связанный с ним ресурс.

Без fence Cleaner теоретически может запустить очистку до фактического завершения нативной операции. Fence продлевает логическую достижимость объекта до конца метода, но не делает очистку синхронной и не заменяет явное управление временем жизни ресурса.

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

В Java время жизни объекта определяется достижимостью, а не областью видимости переменной. JIT-компилятор может анализировать достижимость точнее исходного текста и считать объект мёртвым сразу после последнего использования.

Это стало проблемой для объектов, связанных с JNI, файловыми дескрипторами, памятью вне heap и другими нативными ресурсами. Механизм Reference.reachabilityFence появился в Java 9 как явный способ сообщить JVM: объект должен считаться достижимым до конкретной точки.

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

В примере nativeCall(state) может использовать состояние ресурса дольше, чем Java-код явно обращается к this. Если JIT докажет, что ссылка на Resource больше не влияет на результат метода, объект может стать кандидатом на обработку Cleaner ещё до возврата из use.

Ранний запуск очистки способен закрыть дескриптор, освободить нативную память или инвалидировать структуру, которую ещё использует JNI-код. Ошибка при этом может проявляться редко: она зависит от JIT-компиляции, давления на память и момента работы GC.

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

reachabilityFence(this) создаёт специальную точку достижимости. JVM обязана считать указанный объект достижимым вплоть до выполнения fence, даже если обычный анализ живости уже не видит дальнейшего использования ссылки.

Важные свойства механизма:

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

В коде fence должен находиться после nativeCall. Если вызвать его до нативной операции, он не защищает ресурс во время самой операции. Если нативный код сохраняет указатель и продолжает работу асинхронно после возврата из use, fence уже недостаточен: требуется явный протокол владения, например счётчик активных операций, блокировка или отдельная нативная ссылка.

Cleaner следует рассматривать как аварийный механизм освобождения, а не как замену close. Предпочтительный путь — явное освобождение через try-with-resources; Cleaner нужен для защиты от ошибок вызывающего кода, причём момент его запуска не гарантирован.

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

Сервис использовал Java-обёртку над нативным декодером. Метод передавал нативному коду буфер, а очиститель освобождал нативную структуру при потере обёртки. После включения C2-компиляции иногда появлялись редкие ошибки доступа к уже освобождённой памяти.

Рассматривались три варианта. Полагаться только на Cleaner было просто, но не давало гарантии времени очистки. Полностью отказаться от автоматической очистки повышал риск утечек при исключениях. Добавить reachabilityFence было минимальным исправлением для синхронных вызовов, но не решало бы асинхронное использование.

Выбрали явный close через try-with-resources, fence после каждого синхронного JNI-вызова и отдельный протокол владения для фоновых нативных операций. Это разделило две задачи: fence защищал корректность времени жизни во время вызова, а явное закрытие определяло момент освобождения ресурса.

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

1. Разве наличие локальной переменной this до конца метода не гарантирует жизнь объекта?

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

2. Продлевает ли fence жизнь всех объектов, связанных с Resource?

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

3. Гарантирует ли reachabilityFence выполнение очистки сразу после метода?

Нет. Он только запрещает считать объект недостижимым до точки fence. После неё Cleaner всё ещё работает недетерминированно, а GC может не запускаться долго. Для предсказуемого освобождения дескрипторов и другой ограниченной нативной памяти нужен явный close, желательно в try-with-resources.