questionerКогда объясняют синхронизованные коллекции и зачем они нужны по-моему больше эмоций чем здравого смысла.
То есть, если не понятно, то все вокруг истерички? Интересная позиция.

questionerчто будет если один поток одновременно, скажем, будет добавлять, а другой читать?
Если не использовать итераторы, а только методы коллекций, то в синхронизированой колекции они будут исполнять по очереди.
Использование же обычного ArrayList в многопоточном окружении может привести к непредсказуемым результатам. Перечислать все возможные варианты как оно может сломаться бесполезно.
Например два потока одновременно добавляют элемент, при этом массив внутри ArrayList необходимо расширить. Это закончиться тем что два потока создадут две копии массива и добавят туда свои элементы. А после присвоения в поле, останется доступным лишь одинм массив. Данные добавленные другим потоком пропадут.
Даже без расширения массива, при одновременной записи можно записать два элементы в одну позиуицю.

Если же ограничиться тем, что только один поток пишет и только один поток читает, то проблем, конечно будет меньше. Но нельзя сказать что их не будет совсем. Основная проблема в том что читающий поток может не сразу увидеть то что уже записано. Либо при итерации читатель будет рассчитывать на N элементов. А массиве уже будет меньше. Что приведет к выходу за пределы массива.

Конечно, же, можно огранизовать чтение и запись таким образом чтобы ничего этого не происходило. Пример такого подхода - циклический буфер. Просто там используются другие механизмы синхронизации.

Обычный Collections.synchronized нужен в том случае, если потоки скорее всего конкурировать не будут. Но вероятность того что возможен параллельный доступ не нулевая.

questionerя такого не говорил)

А какие тогда эмоции? Грусть и печаль? :D

questionerэто про синхронизованный или обычный List ?
Это про ArrayList.

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

Нет. Просто появится непредсказуемое поведение. Например баги, которые нельзя воспроизвести, соответсвенно нельзя установить их источник. Соответсвенно нет и возможности их исправить. Потому что у юзера они вылазять регулярно, а девелопер на это отвечает "у меня всё работает".


questioner1. Не спасают от итераторных ConcurrentModificationExcreption?
ConcurrentModificationExcreption к многопоточности отношения не имеет.

questioner2. Производительность падает?
Зависит от сценария использования и реализации. Например Biased Locking оптимизация делает synchronized почти бесплатным, пока он используется единственным потоком.

questionerк потокам доступа к коллекци
Это какой-то особый под-вид потоков? :)