redwhite90Много в интернете информации по поводу вышеприведенных ключевых слов, но на мой взгляд всё как-то однобоко освещено. Хочу написать своё понимание. Поправьте, где не прав.

synchronized - блок кода, куда имеет доступ только один поток(поток 1). Если другим потокам нужен доступ туда, они ждут пока поток 1 покинет его. Когда поток 1 выходит из synchronized (блока/ метода - не важно) - все разделяемые ресурсы синхронизированы. То есть все локальные копии переменных имеют одинаковое значение.

volatile - свойство, накладываемое на поле класса. Говорит о том, что если некий поток изменяет это поле, то на данный момент времени никакой другой поток не может менять значение этой переменной.Также это говорит о том, что в любой момент времени значение этой переменной одинаково для любого потока и соответствует последнему изменению. То есть любой поток напрямую тыркается именно в "подлинную" переменную.
Мое мнение) Изменения в блоке syn видны всем потокам сразу, и для volatile тоже.

JMMдля хранения ссылки на объект можно использовать поле volatile. В этом случае не могут возникнуть проблемы, связанные с тем, что поток, получивший доступ к объекту, созданному в другом потоке, может увидеть этот объект в некорректном состоянии, то есть увидеть устаревшие значения полей объекта. Это гарантируется моделью памяти Java: если поток A читает значение volatile поля, изменённого потоком B, то поток A гарантированно видит результат всех действий, выполненных потоком B до записи значения в volatile поле.

redwhite90, я не знаю) думаю volatile аналогично переменой у которой get и set являются synchronized.

redwhite90rdm,

как обычно тогда...ждём)))

Точно)

авторMemory Consistency Properties

Chapter 17 of The Java™ Language Specification defines the happens-before relation on memory operations such as reads and writes of shared variables. The results of a write by one thread are guaranteed to be visible to a read by another thread only if the write operation happens-before the read operation. The synchronized and volatile constructs, as well as the Thread.start() and Thread.join() methods, can form happens-before relationships. In particular:
Each action in a thread happens-before every action in that thread that comes later in the program's order.
An unlock (synchronized block or method exit) of a monitor happens-before every subsequent lock (synchronized block or method entry) of that same monitor. And because the happens-before relation is transitive, all actions of a thread prior to unlocking happen-before all actions subsequent to any thread locking that monitor.
A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking.
A call to start on a thread happens-before any action in the started thread.
All actions in a thread happen-before any other thread successfully returns from a join on that thread.
The methods of all classes in java.util.concurrent and its subpackages extend these guarantees to higher-level synchronization. In particular:
Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread.
Actions in a thread prior to the submission of a Runnable to an Executor happen-before its execution begins. Similarly for Callables submitted to an ExecutorService.
Actions taken by the asynchronous computation represented by a Future happen-before actions subsequent to the retrieval of the result via Future.get() in another thread.
Actions prior to "releasing" synchronizer methods such as Lock.unlock, Semaphore.release, and CountDownLatch.countDown happen-before actions subsequent to a successful "acquiring" method such as Lock.lock, Semaphore.acquire, Condition.await, and CountDownLatch.await on the same synchronizer object in another thread.
For each pair of threads that successfully exchange objects via an Exchanger, actions prior to the exchange() in each thread happen-before those subsequent to the corresponding exchange() in another thread.
Actions prior to calling CyclicBarrier.await and Phaser.awaitAdvance (as well as its variants) happen-before actions performed by the barrier action, and actions performed by the barrier action happen-before actions subsequent to a successful return from the corresponding await in other threads.

DoSOfRedRiverredwhite90,


Как по вашему два потока могут ОДНОВРЕМЕННО изменить значение перменной? Вам стоит почитать о многопоточности: понятие монитора, семофора, атомарности. Думаю дальше сами разберётесь.
Я думаю он имеел виду являются ли операции с volatile переменными атомарными, я думаю нет.

volatile int a;

a++; // не атомарная

redwhite90забыл никпропущено...

Вообще говоря это неверно. Изменять значение могут все потоки без ограничений. Запись и чтение волатильной переменной тупло создают ребро happens before. Технически это происходит так, компилятор вставляет между этими действиями мембары

осталось узнать что такое "happens before" и "мембары".
1 - происходит до) A happens before B, действие А произойдет раньше B.
2 - мембар - это мемори барьер memory barrier, вроде как эта инструкция говорит процессору синхронизовать свой локальный кэш с общей памятью.

забыл никrdmпропущено...

1 - происходит до) A happens before B, действие А произойдет раньше B.
2 - мембар - это мемори барьер memory barrier, вроде как эта инструкция говорит процессору синхронизовать свой локальный кэш с общей памятью.
Примерно так, по пункту 1 есть дополнения.
Happens-before это специальное отношение между потоками в рамках JMM(Java Memory Model), с помощью которого можно доказывать корректность многопоточного кода. Обычно выполнение программы можно заменить направленным графом вершин happens-before, и по этому графу смотреть, корректна ли программа или нет. Помимо volatile отношениями happens-before связаны блоки synchronized, множество классов из j.u.c , методы Thread.start() Thread.join() и т.д. Ну простейший пример

int a = 2;
Thread.start();

Так вот во втором потоке
if(a == 2)
гарантировано будет видна, так как событие a=2 связано отношением happens-before со стартом второго потока.
Подробнее обо всем этом можно почитать погуглив JMM, поначалу разрывает мозг, особенно с final :) Но после пары прочтений уже начинаешь понимать что к чему), благо она небольшая.
Там еще для final полей, которые инициализируются в конструкторе, hot spot дает гарантии даже если только одно поле final, а остальные обычные. Это к теме безопасной публикации объектов.