DEVcoach, у тебя есть какой-нибудь бенчмарк или юзкейс чтобы мы могли пообсуждать
более предметно? Возможно volatile - это тот самый пингвин которого ты "не умеешь готовить"
или применяешь "не там и не в то время". Это кст. типичная ошибка.

DEVcoach mayton ,
Ну с volatile очень тяжело найти хоть какой-то пример, который что-то продемонстрирует на x86. В этом та и вся проблема, почему его плохо понимают - практически невозможно увидеть глазами результаты от его наличия или отсутствия.
Тогда извини, я рискну предположить что volatile тебе не нужен. Или у тебя нет задач которые требуют
использования volatile.

В теории конечно всё интересно. Но мы будем обмениваться мнениями и цитатами из
документов и спецификаций. В некотором варианте мы здесь должны рисовать графы
со стрелочками и с барьерами и матрицы достижимости. Но я склоняюсь к выводу
что программинг это всё-таки более практическая наука. Тоесть если я создал
какой-то тест-кейс в котором доказал что volatile работает вовсе на так как пишет
теория (в какой-то реализации JVM для какого-то мобильного телефона Samsung SE)
то значит я эту всю теорию разгромил и нам надо вернуться к началу и спросить
а какие собственно будут условия?

Тоесть я возвращаюсь наверх и спрашиваю. DEVcoach. Каковы наши начальные условия?

DEVcoachКоллега, я не могу понять, что вы от меня хотите. Был задан сугубо теоретический вопрос, с помощью которого я хотел понять, как люди видят volatile. Точка. Нет никаких "условий".
Коллега, здесь теории очень мало. Volatile - это не тот термин который обсуждают теоретики.
Это практическая вещь.

В дополнение к тому что сказал jdroid.

Давайте обратимся к документу The Java® Language Specification Java SE 7 Edition

Там есть несколько упоминаний сабж.

The Java® Language Specification Java SE 7 Edition 8.3.1.4 volatile Fields

The Java programming language allows threads to access shared variables (§17.1).
As a rule, to ensure that shared variables are consistently and reliably updated, a
thread should ensure that it has exclusive use of such variables by obtaining a lock
that, conventionally, enforces mutual exclusion for those shared variables.
The Java programming language provides a second mechanism, volatile fields,
that is more convenient than locking for some purposes.
A field may be declared volatile, in which case the Java Memory Model ensures
that all threads see a consistent value for the variable (§17.4).

It is a compile-time error if a final variable is also declared volatile.



This allows method one and method two to be executed concurrently, but guarantees that
accesses to the shared values for i and j occur exactly as many times, and in exactly the
same order, as they appear to occur during execution of the program text by each thread.
Therefore, the shared value for j is never greater than that for i, because each update to
i must be reflected in the shared value for i before the update to j occurs. It is possible,
however, that any given invocation of method two might observe a value for j that is much
greater than the value observed for i, because method one might be executed many times
between the moment when method two fetches the value of i and the moment when method
two fetches the value of j.

The Java® Language Specification Java SE 7 Edition 17.4 Memory Model

....(много букв аж до раздела 17.5)


Ссылка на источник

Если у вас есть другой документ или другая версия - то я не возражаю. Тоже обсуждается.
Но нам в любом случае нужен первоисточник. Не вики и не статьи на хабре а нечто более
первоисходное. Тем более что в авторстве JLS стоит Джеймс Гослинг.

Я не супер-силён в английском и поэтому предлагаю изучить и прокомментировать вместе.

В спорных моментах - можем прогнать test examples.

Ну а если сами не сможет создать свои - то вывод не понимаем зачем это нужно
и не знаем где применить.