О ссылке на объект до завершения конструктора объекта

Нет ли противоречия [в JLS вокруг конструкторов и публикации объектов]?

Я считаю, что это несколько разные вопросы, которые не противоречат друг другу.

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

  public class FinalFieldExample {
      public FinalFieldExample() {
         ...
         // very bad idea because the constructor may not have finished
         FinalFieldExample.f = this;
         ...
      }
  }

Вы также не должны запускать поток в конструкторе:

  // obviously we should implement Runnable here
  public class MyThread extends Thread {
      public MyThread() {
         ...
         // very bad idea because the constructor may not have finished
         this.start();
      }
  }

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

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

В JLS 17.5-1 они не назначают статическое поле внутри конструктора. Они назначают статическое поле в другом статическом методе:

static void writer() {
    f = new FinalFieldExample();
}

Это критическая разница.

В полном примере

class FinalFieldExample { 
    final int x;
    int y; 
    static FinalFieldExample f;

    public FinalFieldExample() {
        x = 3; 
        y = 4; 
    } 

    static void writer() {
        f = new FinalFieldExample();
    } 

    static void reader() {
        if (f != null) {
            int i = f.x;  // guaranteed to see 3  
            int j = f.y;  // could see 0
        } 
    } 
}

Как видите, f не устанавливается до после возврата конструктора. Это означает, что f.x безопасно, потому что это final И конструктор вернулся.

В следующем примере не гарантируется установка ни одного значения.

class FinalFieldExample { 
    final int x;
    int y; 
    static FinalFieldExample f;

    public FinalFieldExample() {
        x = 3; 
        y = 4; 
        f = this; // assign before finished.
    } 

    static void writer() {
        new FinalFieldExample();
    } 

    static void reader() {
        if (f != null) {
            int i = f.x;  // not guaranteed to see 3  
            int j = f.y;  // could see 0
        } 
    } 
}

Согласно утверждению (1) мы должны избегать совместного использования ссылки на неизменяемый объект до того, как его конструктор будет завершен.

Вы не должны разрешать ссылку на объект escape до его создания по ряду причин (неизменяемых или по другим причинам), например. объект может вызвать исключение после того, как вы сохранили объект.

В соответствии с приведенным примером (2) и выводом (3) JLS кажется, что мы можем безопасно делиться ссылкой на неизменяемый объект, т.е. когда все его поля являются окончательными.

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

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

Конструктивный выход играет здесь важную роль; JLS сообщает: «Замораживание последнего поля f из o происходит, когда c завершается». Публикация ссылки до / после выхода из конструктора сильно отличается.

Неформально

1 constructor enter{

2   assign final field

3   publish this

4 }constructor exit

5 publish the newly constructed object

[2] не может быть переупорядочен после выхода из конструктора. поэтому [2] не может быть переупорядочен после [5].

но [2] можно переупорядочить после [3].

Утверждение 1) не говорит о том, что вы думаете. Во всяком случае, я бы перефразировал ваше утверждение:

1) Согласно утверждению (1) мы должны избегать совместного использования ссылки на неизменяемый объект до того, как его конструктор будет завершен.

читать

1) Согласно утверждению (1) мы должны избегать совместного использования ссылки на изменяемый объект до того, как его конструктор будет завершен.

Под изменяемым я подразумеваю объект, который имеет ЛЮБЫЕ неокончательные поля или окончательные ссылки на изменяемые объекты. (должен признать, я не на 100%, что вам нужно беспокоиться об окончательных ссылках на изменяемые объекты, но я думаю, что я прав ...)

Другими словами, следует различать:

• поля final (неизменяемые части возможно неизменяемого объекта)
• незавершенные поля, которые должны быть инициализированы, прежде чем кто-либо взаимодействует с этим объектом
• неокончательные поля, которые не нужно инициализировать, прежде чем кто-либо взаимодействует с этим объектом

Второе - проблемное место.

Таким образом, вы можете делиться ссылками на неизменяемые объекты (все поля final), но вам нужно проявлять осторожность с объектами, у которых есть поля, отличные от final, которые ДОЛЖНЫ быть инициализированы до того, как объект может быть использован кем-либо.

Другими словами, для отредактированного примера JLS, который вы опубликовали, где оба поля равны final, int j = f.y; гарантированно будет окончательным. Но это означает, что вам НЕ нужно избегать записи ссылки на объект f, потому что он всегда будет в правильно инициализированном состоянии, прежде чем кто-либо сможет его увидеть. Вам не нужно беспокоиться об этом, это делает JVM.