privateАсинхронность в жаве - это костыль призванный компенсировать неспособность жавы и JVM эффективно работать с легкими процессами.
А что такое этот ваш "легкий процесс"? Попахивает, что это просто маркетинговый bullshit

В контексте исходного вопроса топика мне очень нравится начало доклада Руслана Черемина на одном из JPoint [spoiler]

Leonid KudryavtsevНу модель памяти в Java ничего общего с Subj не имеет и понимать разбиение heap'а на области - imho желательно, что бы совсем уж говнокод жрущий по 1-2 Gb памяти не писать.
ой ли, JMM как раз имеет непосредственное отношение к concurrency


Leonid KudryavtsevС happens before - я вообще подозреваю, что людей которые в этом разбираются очень мало.
Я бы уточнил, кто разбирается в этом на должном уровне

Leonid KudryavtsevТ.к. например лично я, вообще понять не могу чем store-store порядок от store-load отличается ))) И зачем при наличие store-load синхронизации народ еще в обязательно порядке store-store впихивает )))
имхо, это Вы уже куда-то на уровень реализации полезли

Leonid KudryavtsevНафига нужны volatile и как ими корректно пользоваться, мне не очень понятно, Atomic мне кажется более логичным и понятным классом (хотя визуально объявлены через volatile).
не, здесь как раз все просто, описывается формулой atomic = volatile + CAS

XDiaBLoПро волатайл я с трудом но вроде понял. Добавляет атомичности чтению записи в лонг и дабл
Верно, хотя я бы не конкретизировал про long/double, просто добавляет атомарность

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

XDiaBLoНу и соответственно устанавливает хэппенс-бефо между записью и дальнейшими чтениями.
Верно

XDiaBLoКроме того, когда поток читает такую переменную, он видит не только последнее значение переменной, но и также побочные эффекты кода который привёл к изменению.
Совершенно не факт, что он видит последнее значение переменной, но если он увидел какое то значение, то гарантируется, что он увидит все другие изменения выполненные потоком выполнявшим запись этого значения, которые были выполнены до момента записи в эту переменную.

XDiaBLojust_vladimirСовершенно не факт, что он видит последнее значение переменной
Так у Оракла в туториале написано. Только сегодня этот момент читал. Если врут, ну это печально.
Можно ссылочку?

Leonid Kudryavtsevjust_vladimirне, здесь как раз все просто, описывается формулой atomic = volatile + CAS
Просто хотелось бы пример корректного кода __чисто__ на volatile. Например аналог банального
AtomicInteger.inc
)))
А пока мое IMHO volatile практически бесполезное ключевое слово. О котором достаточно просто знать, что оно есть. (да и то не обязательно). Т.к. на практике или synchronized или Atomic или что-то более сложное для конкретных задач.
getAndIncrement на чистом volatile вы не реализуете, т.к. это требует CAS.

Зачем нужен volatile - здесь просто, допустим у вас есть singleton глобальная static переменная, но которая не volatile, дак вот в этой ситуации у вас нет никакой гарантии, что разные потоки работающие с этой переменной будут видеть действия друг друга, у каждого потока может существовать свой лунапарк с блекджеком и мир, со своей переменной и он будет видеть только свои изменения.


XDiaBLojust_vladimirпропущено...
Можно ссылочку?
Да конечно, хотя ищется легко: https://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html
авторWhat's more, it also means that when a thread reads a volatile variable, it sees not just the latest change to the volatile , but also the side effects of the code that led up the change.
Я не вижу здесь указания на то, что при чтении мы обязаны увидеть именно последнее значение, которое было туда записано. Но вот как только он его увидит, вот тогда уже:
авторbut also the side effects of the code that led up the change

Про то, что не стоит пытаться опуститься на уровень реализации, а нужно постичь дзен JMM можно читать у Шипилева https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/
Впрочем я сколько раз не пытался осилить, так до конца и не осилил))

XDiaBLo,
сойдемся на том, что мы немного по разному понимаем английский язык :-)