Добрый день
Помогите, пожалуйста, разобраться с примером из книги Brian Goetz "Java Concurrency in Practice"

В главе 3.5 Safe Publication он пишет

You cannot rely on the integrity of partially constructed objects.
An observing thread could see the object in an inconsistent state, and then later see its state suddenly change, even though it has not been modified since publication.
In fact, if the Holder in Listing 3.15 is published using the unsafe publication idiom in Listing 3.14,
and a thread other than the publishing thread were to call assertSanity, it could throw AssertionError!

и далее...

...thread may see a stale value the first time it reads a field and then a more up-to-date value the next time, which is why assertSanity can throw AssertionError

Listing 3.14
Listing 3.15

То есть, если я правильно понял, какой-нибудь поток вызывает holder.assertSanity(), читает левое n==42,
прерывается, а потом читает правое n, то оно уже может не быть 42
Как такое может случиться с классом Holder в том виде как он написан в Listing 3.15?

Большое спасибо

Timm
В соответствии с JMM, по-моему разумению, с точки зрения какого-нибудь потока
n может может быть равным любому из значений, записанных в это n другими потоками
Но в данном случае, кто может что-нибудь записать в n после initialize()?

Даже если какой-то поток влезет между чтением левого n и правого n и скажет holder= new Holder(43), это же не изменит правое n?

Есть такие люди тупые и надоедливые
Так это я
Тимм
Если поток А инициализирует holder, до этого еще не инициализированную, то поток В, намеревающийся вызвать holder.assertSanity(), или обламывается, если к этому моменту holder все еще ==null, или видит в holder все, что сделал поток А. Ведь нельзя же в потоке В увидеть holder != null, ссылающийся на не инициализированный или частично инициализированный обьект
Holder?


wessen
Затем управление передается опять потоку B и получается так, что он находится внутри метода объекта, которого нет и об этом потоку B никак не сообщается и продолжает читать вторую n, в которой может быть все что угодно.

Почему же это которого нет. Он есть и на него указывает this, то есть та ссылка, на которой assertSanity() в потоке В был вызван???

Time-out
Надо подумать

wessen
В том то и дело, что поток С вызвав метод initialize() переписал эту ссылку, и та область данных(объект handle, который создал поток А), которую все еще использует поток В, объявлена как неиспользованая и ее в любой момент может занять любой другой поток.

Я против
Когда поток В колбасится внутри assertSanity(), то this -это просто еще одна ссылка на тот обьект,
на котором был вызван holder.assertSanity(). Если поток С скажет в это время holder=new Holder(43), то это никак не повлияет на this в потоке В и на обьект, на который this указывает.
this это final reference. Поэтому всегда внутри assertSanity() this.n==this.n
А то что вы пишите "объявлена как неиспользованая и ее в любой момент может занять любой другой поток.", так это произойдет только после выхода из assertSanity()
Разве не так?

Кажется товарищ понял
Если поток А, который сказал
holder = new Holder(42);
сбросил в heap ссылку holder на только что созданный Holder(42),
то это еще не значит, что он уже сбросил туда же и окончательное состояние этого нового Holder(42). Единственное, что поток А может гарантировать, что ничего другого в n кроме default value для int т.е. 0 или 42 быть не может, причем в порядке: сначала 0 потом 42, не наоборот
Поэтому из указанных т. Timm вариантов
Timm
Можно!! Варианты:
1. holder == null
2. holder != null && n = 0
3. holder != null && n = 42
4. holder != null && n = <что то еще>
+ состояние объекта при чтении в разные моменты времени может быть разным.

Первые три случая могут быть. Насчет четвертого я не уверен.
поток В, выполняющий assertSanity() может увидеть:
в левом n 0, а в правом 0 или 42,
в левом 42, тогда в правом только 42

Праильно???