методы Синхронизировать для предотвращения ConcurrentModificationException

Question

У меня есть 1,8 класс Java, который содержит две коллекции:

Map<Key,Object> 
Set<Object> 

Мой класс пять методов:

addObjectToMap() 
removeObjectFromMap() 
addObjectToSet() 
removeObjectFromSet() 

loopOverEverything(){ 
    for(Object o : mySet){ 
     for(Object o2 : myMap.getKeySet()){ 
      doSomething(o,o2); 
     } 
    } 
} 

Точка класса реализовать шаблон наблюдателя, но быть очень гибкими как в наблюдателях, так и в наблюдениях. Проблема, с которой я сталкиваюсь, заключается в том, что последний метод может легко вызывать исключение ConcurrentModificationException, когда поток вызывает методы add/remove во время цикла. Я думал о синхронизации всех методов на «это»:

set.add(object); 

станет

synchronized(this){ 
    set.add(object); 
} 

, и я хотел бы добавить аналогичное заявление синхронизироваться с другими 4 способами, в том числе метод цикла.

Будет ли это работать? Я знаю, что методы синхронизации могут вызвать узкие места. Несмотря на то, что в настоящее время нет проблемы с производительностью, я хотел бы рационализировать этот дизайн и узнать о возможных альтернативах, которые имеют меньшую производительность.

Answer 1

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

Общей стратегией для проведения соревнований является получение «моментального снимка» слушателей для уведомления перед доставкой любых событий. Поскольку порядок уведомления обозревателей обычно не определен, он действителен для всех наблюдателей, которые были зарегистрированы, когда генерируется событие для его получения, даже если другой наблюдатель отменяет регистрацию в результате этого уведомления.

Чтобы сделать снимок, вы можете скопировать наблюдатель на временную коллекцию или массив:

Collection<?> observers = new ArrayList<>(mySet); 

или

Object[] observers = mySet.toArray(new Object[mySet.size()]); 

Тогда итерации по этой копии, оставляя оригинал для обновления:

for (Object o : observers) { 
    ... 
    doSomething(o, ...); 
    ... 
} 

Некоторые параллельные коллекции, такие как ConcurrentSkipListSet, не будут вызывать исключение , но они только гарантируют «слабо согласованную» итерацию. Это может привести к тому, что некоторые (вновь добавленные) наблюдатели неожиданно получат текущее уведомление. CopyOnWriteArraySet использует технику моментальной съемки. Если вы редко модифицируете набор, он будет более эффективным, потому что он только копирует массив, когда это необходимо.

Answer 2

Один из возможных ответов, который будет работать лучше, чем использование блоков synchronized, - это изменение ваших коллекций в потокобезопасных. Вместо HashMap (или любую другую карту, которую вы используете) используйте ConcurrentHashMap. Замените Set либо CopyOnWriteArraySet, либо ConcurrentSkipListSet. Вам нужно будет прочитать документацию по этим вопросам, чтобы убедиться, что их поведение в потоке - это то, что вы на самом деле хотите, но оба должны быть улучшены по сравнению с небезопасным классом без синхронизации.

Answer 3

Нет, это небезопасно, если петля также не синхронизирована. Если вы хотите избежать накладных расходов на блокировку в течение всего цикла, рассмотрите возможность использования параллельных коллекций, таких как ConcurrentHashMap и Collections.newSetFromMap(new ConcurrentHashMap<>()).