Предположим, что мы написали data race free программу. То есть все куски кода их разных потоков общаются друг с другом исключительно через synchronized-with, и всегда видят актуальные значения.
Вопрос такой: существует ли data race free программа, которая не сможет корректно работать без модификатора final? Ну то есть взяли, например, и выпилили final из Java 8. Пострадает ли от этого хоть одна data race free программа?

P.S.: Вопрос касается final исключительно в контексте concurreny. Другие плюшки вроде complie-time проверок и inner классов оставим за скобками.

забыл ник ,
Я не говорил про synchronized , я говорил про synchronized-with , это разные вещи. То есть у нас есть корректно синхронизированная программа, без гонок. Она работает. Теперь мы берем, и выпиливаем все final. Будет ли она работать и дальше?

Сергей Арсеньев ,
Нет, я не про это. Я про использование final в корректно синхронизированном коде.
Моя идея очень проста - с точки зрения многопоточности, final нужен только в некорректно синхронизированном коде, то есть в коде, где есть data race.

Приведу пример. Есть программка с некорректной публикацией:
Здесь объект holder опубликован небезопасно, поэтому другой поток может увидеть holder.val == null, и ассершн упадет. Окей. тогда мы говорим, а давайте ка мы добавим Holder.val модификатор final, и тогда ассершн никогда не упадет. Ну окей, коллеги, добавьте final, и попробуйте запустить этот код. Программа нормально отработала? То то и оно :-)

Мы добавили final, но программа все равно не работает. Не работает она по причине наличия data race на переменной holder, и читатель не может увидеть ее изменение. Программа некорректна. Окей, я могу это легко исправить, сделав holder volatile:
Окей, holder волатильный, Holder.val финальный. Программа корректно синхронизирвана, в ней нет data race'ов. А теперь вопрос: а нахрена нам теперь нужен final у Holder.val? Он теперь не нужен. Я могу его безопасно удалить, и ассершн никогда не упадет по той причине, что теперь безопасная публикация (действительно безопасная) осуществляется через volatile.

Таким образом, я делаю вывод, что final нужен только в тех случаях, если у нас уже был какой-то косяк в коде, и мы хотим немного его подшлифовать. Если же у нас код корректен, то final не нужен никогда. Пример такого сознательного "косяка" - double checked locking, когда мы сознательно оставляем в коде data race, но при подозрении на его возникновение всегда можем грамотно разрулить ситуацию через тот же final, например.

P.S.: Повторюсь, я говорю про final сейчас исключительно в контексте многопоточности .

P.S

chabapokА если х будет волатил, то видимость z=MyObj(10) гарантируется.Это не так. Давайте посмотрим на такой вот код:

Давайте рассмотрим, как отработает последняя строчка в идеальных условиях, когда у нас нет out-of-order execution:

ref = allocate(MyObject);
ref.x = 1;
ref.y = 2; // За volatile store идет "барьер сверху".
_________
---------
obj = ref;

"Барьер сверху" означает, что присвоение x не может убежать за присвоение y. Однако, следующий вариант также является абсолютно валидным с точки зрения JMM:

ref = allocate(MyObject);
ref.x = 1;
obj = ref;
ref.y = 2;
_________
---------

Таким образом мы увидим объект до того, как была инициализирована его волатильная переменная. Так что volatile и final нельзя сравнивать в таком ключе.

Сергей АрсеньевПоскольку Вы сделали holder volatile, то согласно JMM начиная с 1.5 есть ,есть барьер на операции с памятью, который вроде бы гарантирует окончание конструктора до присвоения, а соответственно до чтения (либо null либо отработавший конструктор).Нет такой гарантии в JMM. Шипилев недавно поднимал эту тему в concurrency-interest, предлагая сделать такую гарантию для volatile, но ее зарубили - http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011951.html

Сергей АрсеньевВообще говоря и final гарантирует это не всегда. Только если конструктор не публикует свое this.Если разработчик объявил поле final, а потом отдал this из конструктора до его инициализации, то это проблема разработчика, а не final.
final дает четкие гарантии при его корректном использовании. Я с таким же успехом могу вам сказать, что synchronized не всегда гарантирует критическую секцию, если использовать разные мониторы.

Еще раз - я говорю про корректно синхронизированную программу, где все инструменты использованы корректно. И я пришел к выводу, что в таких программах final не нужен. У кого есть другие мысли по этому поводу?

Сергей Арсеньев Вы путаете волатильное поле создаваемого объекта с волатильной переменной, которой присваивают создаваемый объект.Да, я не правильно вас понял. Ваше утверждение верно.
Мой поинт как раз в этом и заключается, что если гонок нет, то для final просто напросто нет применений. А если гонка все таки есть, то final никогда не избавит нас от нее, но лишь даст немного более предсказуемые результаты.