java.util.ConcurrentModificationException при итерации LinkedHashSet

Одна вещь, о которой должен знать OP (и, вероятно, большинство людей):

ConcurrentModificationException не имеет ничего общего с многопоточностью.

Хотя многопоточность делает это намного проще, но суть этой проблемы не имеет ничего общего с многопоточностью.

В основном это вызвано такими сценариями, как

1. Получить итератор из коллекции,
2. Прежде чем закончить использование этого итератора, коллекция структурно модифицируется.
3. Продолжайте использовать итератор после 2. Итератор обнаружит, что коллекция структурно изменена, и выдаст исключение ConcurrentModificationException.

Конечно, не все коллекции имеют такое поведение, например. ConcurrentHashMap. Определение «структурно модифицированный» также отличается для разных коллекций.

Это означает, что даже у меня есть только 1 поток, если я сделаю что-то вроде:

    List<String> strings = new ArrayList<String>();
    //....
    for (String s: strings) {  // iterating through the collection
        strings.add("x");   // structurally modifying the collection
    }

Я получу ConcurrentModificationException, даже если все это происходит в одном потоке.

Существуют различные способы решения проблемы, в зависимости от вашего требования или проблемы. например

1. Если это просто из-за многопоточного доступа, правильный синхронизирующий доступ может быть одним из решений.
2. Вы можете использовать коллекцию, в которой итератор защищен от структурных изменений (например, ConcurrentHashMap).
3. Настройте свою логику, чтобы либо повторно получить итератор снова, если вы изменили коллекцию, либо внести изменения с помощью итератора (некоторые реализации коллекции позволяют это), либо убедитесь, что модификация коллекции происходит после того, как вы закончите использовать итератор.

Учитывая, что ваш код, кажется, имеет правильную синхронизацию на alarmHistory, есть два направления, которые вы хотели бы проверить.

1. Возможна ли модификация alarmHistory внутри sendNotification()? Например, добавление или удаление из alarmHistory?
2. Есть ли другой возможный несинхронизированный доступ к alarmHistory, который может изменить структуру?

Если один поток повторяется, а другой добавляется, вы попали в шланг.

Учитывая, что ваш код похоже синхронизирует доступ к двум релевантным блокам кода, найдите другой несинхронизированный код, который добавляет/удаляет из AlarmsHistory.

Единственная мысль, которая приходит мне в голову, что у вас закулисная логика. Я думаю, что sendNotification каким-то образом рекурсивно вызывает addToReplayHistory. Таким образом, многопоточность — отвлекающий маневр, файл журнала показывает только один вовлеченный поток, и сразу же после sendNotification есть вызов addToReplayHistory, который изменяет коллекцию и ломает интератор.

Дополнительная информация находится в javadoc для исключения:

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

Чтобы добавить некоторые детали к ответу Кана:

Блок synchronized в Java является реентерабельным:

Реентерабельная синхронизация

Recall that a thread cannot acquire a lock owned by another thread. But a thread can acquire a lock that it already owns. Allowing a thread to acquire the same lock more than once enables reentrant synchronization. This describes a situation where synchronized code, directly or indirectly, invokes a method that also contains synchronized code, and both sets of code use the same lock. Without reentrant synchronization, synchronized code would have to take many additional precautions to avoid having a thread cause itself to block.

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

То, что вы должны искать, чтобы исправить исключение, - это рекурсивные вызовы между синхронизированными блоками или несинхронизированный доступ к alarmsHistory.

Вы также можете просматривать параллельные коллекции, такие как ConcurrentSkipList или CopyOnWriteArraySet. Оба должны предотвратить исключение, но остерегайтесь их поведения и характеристик производительности, описанных в JavaDoc.