Здравствуйте,
Помогите пожалуйста, разобраться с синхронизацией коллекций в Java
Просьба: если захотите ответить, дочитайте, пожалуйста весь пост до конца, там изложены кое - какие мои соображения, и хотелось бы услышать 
ваше мнение по ним. Я постарался как можно четче изложить суть некоторых моих сомнений.
Спасибо.

Начну вопрос с моего понимания смысла существования необходимости синхронизации...
Для чего вообще предназначена синхронизация...
В моем понимании для 2 вещей - 1) сохранение целостности данных с точки зрения самой программы.(Я имею ввиду что если,с точки зрения программы, определенная 
группа операций должна выполняться как единая транзакция, то есть для программы быть *атомарной* то такую группу нужно синхронизировать)
2) сохранение целостности структур данных с точки зрения JVM(имею ввиду избежания всякого рода ConcurrentModificationException и тд)

Вот цитаты из javadoc для ArrayList и HashMap
ArrayList - 
If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies 
the list structurally, it must be synchronized externally. (A structural modification is any operation that 
adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an 
element is not a structural modification.)

то есть, как я понимаю, операцию set() синхронизировать не нужно? 

HashMap - 
If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.)

то есть, как я понимаю, я могу *потокобезопасно* читать с Мапа, и кроме того !!! *потокобезопасно* модифицировать value для этого метода, при этом ничего 
не синхронизировав ?

У меня по этому поводу возникло 2 вопроса и несколько выводов

Допустим у меня в программе невозможно отказаться от обычных структур данных(не использовать synchronized* структуры, ,блокирующие очереди ConcurrentAPI
и тд, НУ допустим так... ) 
1) множеством потоков я читаю из HashMap и одним-единственным модифицирую value для уже имеющегося ключа, то есть я не удаляю/добавляю мапинги, а просто 
привязываю к ключу новый value. В таком же случае,судя по javadoc, синхронизировать доступ к Мапу не нужно, так ведь? А что если я начну модифицировать values 
для мапа не 1 а несколькими потоками ? Опять таки,судя по javadoc, это не структурная операция => её синхронизировать не нужно, так ? Ну а вот ,вдруг,будет 
такая ситуация, что сразу 2 модифицирующих потока будут писать значения по одинаковому ключу, что тогда ? Я предполагаю, что с точки зрения сохранности *моих*
данных - будет плохо,но JVM считает что это уже *мои* проблемы, а с точки зрения JVM такое поведение допустимо и никаких Exceptions сгенерированно не будет. 
Я прав?
СМ: PS
2) такая же ситуация что и в предыдущем вопросе. На сей раз ArrayList. Судя по Javadoc я без проблем могу читать из него несколькими потоками, ничего не синхронизируя. Опять таки там пишется, что запись элемента под уже существующем индексом - не структурая операция. Следовательно с точки зрения
JVM set() тоже можно не синхронизировать.
Давайте посмотрим на код set() из ArrayList :

Понятно, что с точки зрения *моих* данных, хранящихся в этом ArrayList асинхронный set() смерти подобен,в том случае если я полагаюсь на 
значение возвращаемое setом,ведь допустим ситуацию - 
поток1 заходит в set() выполняет строку4 и вытесняется, после чего поток2 проходит весь set() полностью,после чего раздупляется поток1 ставит свой element
и возвращает значение установленное не потоком2 а то которое он забрал до захода потока2 в set(). 
Объяснение такой трактовки в javadoc вижу такое же, как и описанно в вопросе выше (1) : с точки зрения JVM все корректно: мол - ну ставят несколько потоков 
разные значения , ну и что ?...
Посмотрите,пожалуйста, секцию PS где я пишу из-за чего,по моему  мнению, так происходит.

Мой вывод1 - для того чтоб не развалить сам *JVM* ConcurrentModificationExceptionоами и прочим, синхронизировать нужно *только* *структурные* операции
вывод2 - если ты просто читаешь с структуры - синхронизация не обязательна
           - если читаешь и пишешь(изменяешь структурно) обязательная синхронизация, чтоб не развалилась JVM и данные программы были в целостности
           - если пишешь(не структурно) *НО* с точки зрения программы данные могут быть поврежденны(то есть группа операций по модифицированию данных 
*обязательно* должна выполнятся атомарно) нужно синхронизириовать(локами, синхронайзом методов, синхронизированными блоками и тд)
           - если читаешь и пишешь(не важно структурно или нет) синхронизировать нужно readWriteLock'ом
 
PS: может, такие строки(СМ пункты javadoc выше) есть в javadoc из-за того что с точки зрения JVM операция записи/обновления ссылки(адреса) в памяти для элементов(в ArrayList) и для  value(в Map) атомарна и поток не может быть вытеснен начав её обновлять/записывать и не закончив ? Объясните, пожалуйста...
Сам, вот уже сажусь за Дуга Ли, но там 400 стр и на английском, не знаю как скоро освою. 


Это сообщение отредактировал(а) novichiok - 20.10.2011, 14:00

по идее нет, во всяком случае ConcurrentModificationException  вываливаться не должно, насколько я понимаю. Но если скажем вы работаете со сложным объектом. Один поток читает его, а второй изменяет. В результате целостность объекта может быть нарушена.  

1. Нужно. Если Вы выставляете значение ссылки в потоке 1, то в потоке 2 без синхронизации никто не гарантирует корректного чтения. Когда-то эта ссылка дойдет и до потока 2, но совершенно необязательно сразу.

2. Полностью аналогично. Вычитать Вы можете старые данные после того, как они уже поменялись. 

Это сообщение отредактировал(а) Skipy - 19.10.2011, 17:07

На самом деле это одна вещь - сохранение целостности обьектов. И данные и коллекции данных - обьекты. В стандартные библиотечные классы (например, в упомянутые коллекции) уже включены средства контроля (типа ConcurrentModificationException), а ответственность за синхронизацию обьектов любых других классов (данные) полностью лежит на создателях этих классов, т.е. да, "это уже *мои* проблемы".

Skipy,  ваши труды по потокам бесценны, сам периодами заглядываю в них (хотя вот конкретно по коллекциям там маловато). Но, тем не менее. Позвольте не согласиться по поводу категоричности "нужно".
Скажем доступ к объекту Integer. Есть два потока. Один на чтение, другой на запись. Допустим вы синхронизируете доступ к этому объекту. Поток на чтение занял монитор и не дает пишущему доступ. Прочитал и отправился отдыхать, в то время, когда записывающий поток мог бы в конкурентной борьбе забить туда данные и на этом итерация бы закончилась. 
Со сложными объектами немного будет сложнее. Может прийти частично обновленный объект, что почти всегда критично. Но и тут не обязательно синхронизировать set (а это значит List). Достаточно засинкать сам объект, который хронится в List'e. 
Синхронизация List'a будет нужна в случае добавления удаления туда\оттуда элемента. Что и сказано в документации.
Разве нет?   

Это сообщение отредактировал(а) priam220 - 19.10.2011, 18:24

Ну это я и имел ввиду в своем посте. То что я не синхронизирую сеттеры для коллекции - опасно *только* для логики моей программы (читаются старые данные и тд и тп) Но в то же время JVMу абсолютно не кретично синхронизация сеттеров у коллекций, ведь JVM ничего не знает как там что у меня работает, так ведь ? 

+ еще, можете ,пожалуйста, высказаться по поводу цитат с javadoc'а ... У меня с них начало немного рушится мировозрение =) , и буду очень благодарен если более опытные люди отпишутся по этому поводу. + глянуть секцию PS из 1-го поста и мои там размышления 
Спасибо

Добавлено через 7 минут и 17 секунд


В этой теме я имею ввиду set() *только* коллекций в Java. Спрашиваю потому что прочитал javadoc и меня смутили цитаты, которые я привел в 1-ом посте. Понятно что для своих каких то объектов с состоянием синхронизация сеттеров нужна

Нет.

Допустим у Вас есть List. В нем есть массив, в котором какие-то элементы заполнены. В одном потоке Вы меняете значение одного элемента массива через set - меняете Вы ссылку в массиве. В другом потоке после этого Вы можете получить еще старое значение (старую ссылку), поскольку объект типа List, в котором и содержится массив, Вы не синхронизировали.

Skipy, вы рассматриваете заведомо выгодную ситуацию для синхронизации,  - синхронизированная запись, потом чтение... А если наоборот - сначало синхронизированное чтение, потом произошла запись (речь идет об асинхронных операциях)? 
К тому же засинканый List должен ощутимо замедлять работу, если потоков будет много.

Товарищи. Вопрос изначально ставился так  - "set() для коллекции не структурная операция => её можно не синхронизировать ****с точки зрения JVM****" О сохранности логических данных в этой коллекции речи не шло...

Skipy, операция set должна быть синхронизирована в том случае, если List может быть спонтанно удален. Т.е. существует вероятность того, что вызов set приведет к NPE. Но это лучше решить локальной сихронизацией. Как вы считаете?