Коллекция была изменена; операция перечисления может не выполняться

Скорее всего, происходит то, что SignalData косвенно изменяет словарь подписчиков под капотом во время цикла и приводит к этому сообщению. Вы можете проверить это, изменив

foreach(Subscriber s in subscribers.Values)

To

foreach(Subscriber s in subscribers.Values.ToList())

Если я прав, проблема исчезнет.

Вызов subscribers.Values.ToList() копирует значения subscribers.Values в отдельный список в начале foreach. Ни у кого другого нет доступа к этому списку (у него даже нет имени переменной!), Поэтому ничто не может изменить его внутри цикла.

Когда подписчик отказывается от подписки, вы изменяете содержимое коллекции подписчиков во время перечисления.

Есть несколько способов исправить это, один из них - изменить цикл for для использования явного .ToList():

public void NotifySubscribers(DataRecord sr)  
{
    foreach(Subscriber s in subscribers.Values.ToList())
    {
                                              ^^^^^^^^^  
        ...

На мой взгляд, более эффективный способ - иметь другой список, в который вы заявляете, что помещаете в него все, что «подлежит удалению». Затем после завершения основного цикла (без .ToList ()) вы выполняете еще один цикл над списком «подлежащих удалению», удаляя каждую запись по мере ее появления. Итак, в своем классе вы добавляете:

private List<Guid> toBeRemoved = new List<Guid>();

Затем вы меняете его на:

public void NotifySubscribers(DataRecord sr)
{
    toBeRemoved.Clear();

    ...your unchanged code skipped...

   foreach ( Guid clientId in toBeRemoved )
   {
        try
        {
            subscribers.Remove(clientId);
        }
        catch(Exception e)
        {
            System.Diagnostics.Debug.WriteLine("Unsubscribe Error " + 
                e.Message);
        }
   }
}

...your unchanged code skipped...

public void UnsubscribeEvent(Guid clientId)
{
    toBeRemoved.Add( clientId );
}

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

Вы также можете заблокировать словарь подписчиков, чтобы предотвратить его изменение при зацикливании:

 lock (subscribers)
 {
         foreach (var subscriber in subscribers)
         {
               //do something
         }
 }

Почему эта ошибка?

Как правило, коллекции .Net не поддерживают одновременное перечисление и изменение. Если вы попытаетесь изменить список коллекции во время перечисления, возникнет исключение. Итак, проблема, стоящая за этой ошибкой, заключается в том, что мы не можем изменить список / словарь, пока мы просматриваем то же самое.

Одно из решений

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

Пример

//get key collection from dictionary into a list to loop through
List<int> keys = new List<int>(Dictionary.Keys);

// iterating key collection using a simple for-each loop
foreach (int key in keys)
{
  // Now we can perform any modification with values of the dictionary.
  Dictionary[key] = Dictionary[key] - 1;
}

Вот блог опубликовать об этом решении.

И для более глубокого изучения StackOverflow: Почему возникает эта ошибка?

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

for (int x = myList.Count - 1; x > -1; x--)
{
    myList.RemoveAt(x);
}

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

Что вам действительно нужно сделать, так это начать с конца и вернуться к началу. Даже если вы удалите элементы из списка, вы сможете продолжить его чтение.

InvalidOperationException- Произошло исключение InvalidOperationException. Он сообщает, что "коллекция была изменена" в цикле foreach

Используйте оператор break после удаления объекта.

ex:

ArrayList list = new ArrayList(); 

foreach (var item in list)
{
    if(condition)
    {
        list.remove(item);
        break;
    }
}

Принятый ответ неточен и в худшем случае неверен. Если изменения были внесены в течение ToList(), вы все равно можете получить ошибку. Помимо lock, производительность и безопасность потоков которой необходимо учитывать, если у вас есть открытый член, правильным решением может быть использование неизменяемые типы.

В общем, неизменяемый тип означает, что вы не можете изменить его однажды созданное состояние. Итак, ваш код должен выглядеть так:

public class SubscriptionServer : ISubscriptionServer
{
    private static ImmutableDictionary<Guid, Subscriber> subscribers = ImmutableDictionary<Guid, Subscriber>.Empty;
    public void SubscribeEvent(string id)
    {
        subscribers = subscribers.Add(Guid.NewGuid(), new Subscriber());
    }
    public void NotifyEvent()
    {
        foreach(var sub in subscribers.Values)
        {
            //.....This is always safe
        }
    }
    //.........
}

Это может быть особенно полезно, если у вас есть публичный участник. Другие классы всегда могут foreach работать с неизменяемыми типами, не беспокоясь об изменении коллекции.

У меня была такая же проблема, и она была решена, когда я использовал цикл for вместо foreach.

// foreach (var item in itemsToBeLast)
for (int i = 0; i < itemsToBeLast.Count; i++)
{
    var matchingItem = itemsToBeLast.FirstOrDefault(item => item.Detach);

   if (matchingItem != null)
   {
      itemsToBeLast.Remove(matchingItem);
      continue;
   }
   allItems.Add(itemsToBeLast[i]);// (attachDetachItem);
}

Я видел много вариантов для этого, но для меня этот был лучшим.

ListItemCollection collection = new ListItemCollection();
        foreach (ListItem item in ListBox1.Items)
        {
            if (item.Selected)
                collection.Add(item);
        }

Затем просто прокрутите коллекцию.

Имейте в виду, что ListItemCollection может содержать дубликаты. По умолчанию ничто не препятствует добавлению дубликатов в коллекцию. Чтобы избежать дублирования, вы можете сделать это:

ListItemCollection collection = new ListItemCollection();
            foreach (ListItem item in ListBox1.Items)
            {
                if (item.Selected && !collection.Contains(item))
                    collection.Add(item);
            }

Хочу указать на другой случай, не отраженный ни в одном из ответов. У меня есть Dictionary<Tkey,TValue> общий доступ в многопоточном приложении, которое использует ReaderWriterLockSlim для защиты операций чтения и записи. Это метод чтения, который вызывает исключение:

public IEnumerable<Data> GetInfo()
{
    List<Data> info = null;
    _cacheLock.EnterReadLock();
    try
    {
        info = _cache.Values.SelectMany(ce => ce.Data); // Ad .Tolist() to avoid exc.
    }
    finally
    {
        _cacheLock.ExitReadLock();
    }
    return info;
}

В целом работает нормально, но время от времени получаются исключения. Проблема заключается в тонкости LINQ: этот код возвращает IEnumerable<Info>, который все еще не перечисляется после выхода из раздела, защищенного блокировкой. Таким образом, он может быть изменен другими потоками перед перечислением, что приведет к исключению. Решение состоит в том, чтобы принудительно выполнить перечисление, например, с помощью .ToList(), как показано в комментарии. Таким образом, перечислимый объект уже пронумерован перед тем, как покинуть защищенный раздел.

Итак, если вы используете LINQ в многопоточном приложении, не забывайте всегда материализовать запросы перед тем, как покинуть защищенные области.

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

для ссылки на исходную ссылку: - https://bensonxion.wordpress.com/2012/05/07/serializing-an-ienumerable-produces-collection-was-modified-enumeration-operation-may-not-execute/

Когда мы используем классы .Net Serialization для сериализации объекта, определение которого содержит тип Enumerable, то есть коллекцию, вы легко получите InvalidOperationException с сообщением «Коллекция была изменена; операция перечисления может не выполняться», когда ваше кодирование выполняется в многопоточных сценариях. Основная причина заключается в том, что классы сериализации будут перебирать коллекцию через перечислитель, поэтому проблема заключается в попытке перебрать коллекцию при ее изменении.

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

Что ж, .Net 4.0, которая делает работу с многопоточными сценариями удобной. Я обнаружил, что для этой проблемы с сериализацией поля Collection мы можем просто воспользоваться классом ConcurrentQueue (Check MSDN), который является поточно-ориентированной коллекцией FIFO и делает код без блокировки.

Используя этот класс, в его простоте, вещи, которые вам нужно изменить для вашего кода, заменяют им тип Collection, используйте Enqueue, чтобы добавить элемент в конец ConcurrentQueue, удалите этот код блокировки. Или, если сценарий, над которым вы работаете, требует сбора таких вещей, как List, вам понадобится еще несколько кода, чтобы адаптировать ConcurrentQueue к вашим полям.

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

Вот конкретный сценарий, требующий особого подхода:

1. Dictionary перечисляется часто.
2. Dictionary изменяется нечасто.

В этом сценарии создание копии Dictionary (или Dictionary.Values) перед каждым перечислением может быть довольно дорогостоящим. Моя идея решения этой проблемы состоит в том, чтобы повторно использовать одну и ту же кэшированную копию в нескольких перечислениях и следить за IEnumerator оригинального Dictionary на предмет исключений. Перечислитель будет кэширован вместе с скопированными данными и опрошен перед началом нового перечисления. В случае исключения кешированная копия будет отброшена, и будет создана новая. Вот моя реализация этой идеи:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;

public class EnumerableSnapshot<T> : IEnumerable<T>, IDisposable
{
    private IEnumerable<T> _source;
    private IEnumerator<T> _enumerator;
    private ReadOnlyCollection<T> _cached;

    public EnumerableSnapshot(IEnumerable<T> source)
    {
        _source = source ?? throw new ArgumentNullException(nameof(source));
    }

    public IEnumerator<T> GetEnumerator()
    {
        if (_source == null) throw new ObjectDisposedException(this.GetType().Name);
        if (_enumerator == null)
        {
            _enumerator = _source.GetEnumerator();
            _cached = new ReadOnlyCollection<T>(_source.ToArray());
        }
        else
        {
            var modified = false;
            if (_source is ICollection collection) // C# 7 syntax
            {
                modified = _cached.Count != collection.Count;
            }
            if (!modified)
            {
                try
                {
                    _enumerator.MoveNext();
                }
                catch (InvalidOperationException)
                {
                    modified = true;
                }
            }
            if (modified)
            {
                _enumerator.Dispose();
                _enumerator = _source.GetEnumerator();
                _cached = new ReadOnlyCollection<T>(_source.ToArray());
            }
        }
        return _cached.GetEnumerator();
    }

    public void Dispose()
    {
        _enumerator?.Dispose();
        _enumerator = null;
        _cached = null;
        _source = null;
    }

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

public static class EnumerableSnapshotExtensions
{
    public static EnumerableSnapshot<T> ToEnumerableSnapshot<T>(
        this IEnumerable<T> source) => new EnumerableSnapshot<T>(source);
}

Пример использования:

private static IDictionary<Guid, Subscriber> _subscribers;
private static EnumerableSnapshot<Subscriber> _subscribersSnapshot;

//...(in the constructor)
_subscribers = new Dictionary<Guid, Subscriber>();
_subscribersSnapshot = _subscribers.Values.ToEnumerableSnapshot();

// ...(elsewere)
foreach (var subscriber in _subscribersSnapshot)
{
    //...
}

К сожалению, эта идея в настоящее время не может использоваться с классом Dictionary в .NET Core 3.0, поскольку этот класс не генерирует исключение Коллекция была изменена при перечислении и методы _ 10_ и _ 11_. Все остальные контейнеры, которые я проверял, работают стабильно. Я систематически проверял эти классы: List<T>, Collection<T>, ObservableCollection<T>, HashSet<T>, SortedSet<T>, Dictionary<T,V> и SortedDictionary<T,V>. Только два вышеупомянутых метода класса Dictionary в .NET Core не делают перечисление недействительным.

Обновление: я исправил указанную выше проблему, сравнив также длину кэшированной и исходной коллекции. Это исправление предполагает, что словарь будет передан непосредственно в качестве аргумента конструктору EnumerableSnapshot, и его идентификатор не будет скрыт (например) проекцией типа: dictionary.Select(e => e).ΤοEnumerableSnapshot().

Важно! Указанный выше класс не потокобезопасен. Он предназначен для использования из кода, работающего исключительно в одном потоке.

Этот способ должен охватывать ситуацию параллелизма, когда функция вызывается снова, пока все еще выполняется (а элементы необходимо использовать только один раз):

 while (list.Count > 0)
 {
    string Item = list[0];
    list.RemoveAt(0);
 
    // do here what you need to do with item
 
 } 
 

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

Вы можете скопировать объект словаря подписчиков в тот же тип объекта временного словаря, а затем выполнить итерацию объекта временного словаря с помощью цикла foreach.

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