Является ли поточно-ориентированная ленивая инициализация ссылок, если записанное значение всегда одно и то же?

Этот вопрос о 32-битных примитивах аналогичен, но я хочу подтвердить, что поведение одинаково для ссылок на такие объекты, как строки и списки.

Да, потому что написание ссылок всегда атомарно по JLS:

Запись и чтение ссылок всегда атомарны, независимо от того, реализованы ли они как 32-битные или 64-битные значения.

Питер Лоури отмечает, что это действительно начиная с Java 5.

Но обратите внимание на Наблюдение Ивана:

Без синхронизации (блок синхронизации или изменчивый) вы можете получить каждый поток, имеющий свой собственный экземпляр списка (каждый поток может видеть этот views == null и инициализировать переменную и использовать свою собственную копию списка)

... и вопрос Эриксона:

В этой реализации каждый поток может иметь отдельный экземпляр views. Все хорошо?

Ваш код не обязательно является потокобезопасным. Хотя [w] обряды и чтение ссылок всегда атомарны ..., [1] Модель памяти Java не гарантирует, что объект будет полностью инициализирован при обращении к нему другими потоками. Модель памяти Java гарантирует только то, что поля объекта final будут инициализированы до того, как какие-либо потоки смогут увидеть ссылку на него:

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

JSR-133: модель памяти Java и спецификация потока

Таким образом, если реализация ListUtil.toUnmodifiableList(viewsListString); возвращает объект List, который имеет какие-либо незавершенные поля, возможно, что другие потоки увидят ссылку List до инициализации незавершенных полей.

Так, например, предположим, что реализация метода toUnmodifiableList() выглядела примерно так:

public static List<String> toUnmodifiableList(final String viewsString) {
    return new AbstractList<String>() {
        String[] viewsArray = viewsString.split(",");
        @Override
        public String get(final int index) {
            return viewsArray[index];
        }
    };
}

Поток A вызывает getViews(servletContext) и находит views как null, поэтому пытается инициализировать views.

Во время вызова toUnmodifiableList() JVM выполняет оптимизацию и переупорядочивает инструкции так, чтобы произошло следующее выполнение:

views = /* Reference to AbstractList<String> prior to initialization */
this.views = views;
/* new AbstractList<String>() occurs and viewsString.split(",") completes */

Пока поток A выполняется, поток B вызывает getViews(servletContext) после того, как поток A выполняет this.views = views;, но до завершения viewsString.split(",").

Теперь поток B имеет ссылку на this.views, где this.views.viewsArray равно null, поэтому любые вызовы this.views.get(index) приведут к NullPointerException.

Чтобы обеспечить безопасность потоков, любой объект, возвращаемый getViews(), должен был бы гарантировать, что он имеет только final поля, чтобы гарантировать, что ни один поток никогда не увидит частично инициализированный объект (или вы можете гарантировать, что неинициализированные значения обрабатываются правильно в объекте , но это, скорее всего, невозможно). Я считаю, что вам нужно убедиться, что все Object ссылки в объекте, возвращаемом getViews(), также имеют только final поля. Поэтому, если вы вернули List, который содержал final ссылку на MyClass, вам нужно будет убедиться, что все члены MyClass тоже final.

Для получения дополнительной информации посетите: Частично созданные объекты в памяти Java Модель.