Вот здесь можно ответ посмотреть https://youtu.be/C6b_dFtujKo
потому что thread 2 может закешировать у себя значение INSTANCE и думать, что оно все еще null. volatile гарантирует, что все потоки видят согласованное значение переменной.
Потому что volatile write happens before volatile read ? По спецификации гарантируется, что если тред 1 записал в волатиную переменную значение, последующий тред прочитает прочитает актуальное значение
Потому что есть happens-before между записью и последующим чтением. Т.е. есть гарантия, что после записи в переменную её актуальное значение будет видно всем. Это контракт. Реализация на разных платформах может быть разной. На x86, если не ошибаюсь, это приводит к тому, что некий буфер, который содержит записи, сбрасывается в основную память.
"тред закэшировать" - это сразу "а-а-а-а-а!" нельзя в таких терминах модель памяти объяснять. У тредов вообще никаких особых кэшей нет. У процессоров/ядер есть, но тред может переехать на другое ядро в любой момент. Вообще не надо пытаться это объяснить с точки зрения железа. Это будет сложно и скорее всего неверно
Видео смотрели? Может, конечно, я плохо объяснил, не исключаю
Про "буфер" и "основную память" лучше тоже не начинать. Надо просто абстрагироваться от железа и принять правила игры JMM.
По памяти, вроде вполне понятно было. Щас конеч от ненадобности материал уже ватно помню
Да, видео весь день пересматриваю, вроде дошло) Нет hb -> компилятор как-то может строки местами поменять и поэтому х можем не актуальный прочитать 🤔
Я хотел противопоставить JMM как контракт против реализации.
Обсуждают сегодня