Возможный дубликат:
Возможная память в ConcurrentBag?
Edit1:
Реальный вопрос. Можете ли вы подтвердить это или мой образец неправильно, и я не вижу ничего очевидного?
Я думал, что ConcurrentBag просто заменяет список unorderd. Но я был неправ. ConcurrentBag добавляет себя как ThreadLocal к создающему потоку, который в основном вызывает утечку памяти.
class Program
{
static void Main(string[] args)
{
var start = GC.GetTotalMemory(true);
new Program().Start(args);
Console.WriteLine("Diff: {0:N0} bytes", GC.GetTotalMemory(true) - start);
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Thread.Sleep(5000);
}
private void Start(string[] args)
{
for (int i = 0; i < 1000; i++)
{
var bag = new ConcurrentBag<byte>();
bag.Add(1);
byte by;
while (bag.TryTake(out by)) ;
}
}
Я могу сделать Diff 250 КБ или 100 ГБ в зависимости от того, сколько данных я добавляю в пакеты. Данные и мешки уходят.
Когда я врываюсь в это с помощью Windbg, и я делаю Параметр DumpHeap Concurrent
....
000007ff00046858 1 24 System.Threading.ThreadLocal`1+GenericHolder`3[[System.Collections.Concurrent.ConcurrentBag`1+ThreadLocalList[[System.Byte, mscorlib]], System],[System.Threading.ThreadLocal`1+C0[[System.Collections.Concurrent.ConcurrentBag`1+ThreadLocalList[[System.Byte, mscorlib]], System]], mscorlib],[System.Threading.ThreadLocal`1+C0[[System.Collections.Concurrent.ConcurrentBag`1+ThreadLocalList[[System.Byte, mscorlib]], System]], mscorlib],[System.Threading.ThreadLocal`1+C0[[System.Collections.Concurrent.ConcurrentBag`1+ThreadLocalList[[System.Byte, mscorlib]], System]], mscorlib]]
000007feed812648 2 64 System.Collections.Concurrent.ConcurrentStack`1[[System.Int32, mscorlib]]
000007feece41528 1 112 System.Collections.Concurrent.CDSCollectionETWBCLProvider
000007ff000469e0 1000 32000 System.Threading.ThreadLocal`1+Boxed[[System.Collections.Concurrent.ConcurrentBag`1+ThreadLocalList[[System.Byte, mscorlib]], System]]
000007feed815900 1000 32000 System.Collections.Concurrent.ConcurrentStack`1+Node[[System.Int32, mscorlib]]
000007ff00045530 1000 72000 System.Collections.Concurrent.ConcurrentBag`1+ThreadLocalList[[System.Byte, mscorlib]]
Когда я создаю пустой ConcurrentBag, чтобы некоторые рабочие потоки добавляли в него данные, ConcurrentBag и его данные будут там, пока создающий поток все еще жив.
Таким образом, я получил утечку памяти в несколько ГБ. Я "исправил" это, используя список и блокировки. ConcurrentBag может быть быстрым, но бесполезно, как простая замена списка с тем же самым сроком жизни объекта.
Если я когда-либо создаю ConcurrentBag в основном потоке, я буду хранить его до тех пор, пока поток будет жив. Это не то, что я ожидаю, и это может вызвать серьезную боль.
Вы правы, что ConcurrentBag создает копию ThreadLocal, на самом деле они оптимизированы для сценариев, где один и тот же поток читает и записывает данные в сумку: "... ConcurrentBag - это реалистичная реализация пакетов, оптимизированная для сценариев где тот же поток будет производить и потреблять данные, хранящиеся в сумке".
С другой стороны, я не вижу здесь странного поведения; нить живет, и совместная сумка живет. Когда поток заканчивается, GC выполнит эту работу.
Из документации
ConcurrentBag представляет собой реалистичную реализацию пакетов, оптимизированную для сценариев, где один и тот же поток будет производить и потреблять данные, хранящиеся в сумке.
и Когда использовать поточно-безопасную коллекцию
В смешанных сценариях производитель-потребитель ConcurrentBag обычно намного быстрее и более масштабируемо, чем любой другой тип одновременного сбора для больших и малых рабочих нагрузок.
Я бы сказал, что ваши предположения о ConcurrentBag неверны. Во-первых, он не добавляет его в ThreadLocal, он использует локальное хранилище потоков для предоставления отдельных внутренних списков для каждого потока, который обращается к нему. Это больше, чем просто беспорядочный неупорядоченный список.
То, что вы считаете утечкой памяти, на самом деле является ожидаемым поведением, когда вы понимаете, что сумка использует TLS - нет необходимости очищать данные до тех пор, пока поток используется.
Сказав все это, я до сих пор не понял дополнительных функций ConcurrentBag, пока только.
Я нашел очень хорошее описание того, как ConcurrentBag использует отдельные списки и стоимость его методов в разных сценариях в Что такое ConcurrentBag ". Я хотел бы, чтобы это описание появилось в документации MSDN.
Лично я начну использовать ConcurrentBag намного больше, чтобы узнать о его особом поведении.
UPDATE:
Просто проверил этот пост Айенде, говоря, что "ThreadLocal, который использует ConcurrentBag, не ожидал, что будет много экземпляров. Это исправлено, и теперь может работать довольно быстро"
Почему бы не переместить Console.WriteLine после второго GC.Collect()? В противном случае вы можете искать еще несколько объектов, чем вы планировали.
Вы также можете попробовать положить все в свой Main в цикл, чтобы получить несколько статистических данных. Даже если вы не будете перемещать свою запись, вы, вероятно, позже увидите более мелкие дельта.
Ура!