Java: каков правильный способ гарантировать, что неконечное поле ссылки никогда не будет прочитано как нулевое?

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

class Publisher<T> {
  private final T value;
  private Publisher(T value) { this.value = value; }
  public static <S> S publish(S value) { return new Publisher<S>(value).value; }
}

Теперь вы можете создать свой экземпляр с помощью:

Holder holder = Publisher.publish(new Holder(value));

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

Если это единственное использование вашего класса, то вы, конечно, должны добавить в свой класс удобную фабрику и сделать сам конструктор private, чтобы избежать небезопасной конструкции.

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

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

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

Если вы публикуете объект без надлежащей синхронизации, с переупорядочением, потребитель объекта Holder все еще может видеть частично созданный объект, если ссылка на объект была опубликована до завершения конструктора. Например, блокировка с двойной проверкой без volatile.

Есть несколько способов безопасно опубликовать объект:

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

Обратите внимание, что в этих пунктах говорится о ссылке на объект Holder, а не о полях класса.

Так что проще всего будет первый вариант:

public static Holder holder = new Holder("Some value");

Любой поток, обращающийся к статическому полю, увидит правильно сконструированный объект Holder.

См. раздел 3.5.3 «Идиомы безопасной публикации» книги Параллелизм Java на практике. Дополнительные сведения о небезопасной публикации см. в разделе 16.2.1 документа Java Concurrency на практике.

См. раздел 17.5 Спецификации языка Java< /а>.

class Holder {

  private final Object ref;

  Holder(final Object obj) {
    if (obj == null) {
      throw new NullPointerException();
    }
    ref = obj;
  }

  Object get() {
    return ref;
  }
}

class Holder {

  private Object ref;

  Holder(final Object obj) {
    if (obj == null) {
      throw new NullPointerException();
    }
    synchronized (this) {
      ref = obj;
      notifyAll();
    }
  }

  synchronized Object get() {
    while (ref == null) {
      try {
        wait();
      } catch (final InterruptedException ex) { }
    }
    return ref;
  }
}

Невозможно гарантировать, что неконечная ссылка никогда не будет нулевой.

Даже если вы правильно инициализируете его и гарантируете, что в установщике не будет null, все равно можно установить ссылку на null через отражение.

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

Это; тем не менее, все еще возможно переопределить окончательный геттер и заставить его возвращать ноль. Вот ссылка, которая описывает, как смоделировать окончательный метод: насмешка с окончательным методом

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