Оставшаяся оперативная память после завершения всех потоков - PullRequest
Новая
       22

Оставшаяся оперативная память после завершения всех потоков

0 голосов
/ 16 мая 2018

В C # предположим, что вы выполняете много потоков, делая много вычислений с большим количеством объектов и оперативной памятью.В конце концов, все темы сделаны.Затем вы запускаете GC.Collect().Вы просто не останавливаете процесс.

За исключением случаев, когда вы сохраняете ссылки на некоторые объекты в статических переменных, я ожидаю, что в конечном итоге используемая оперативная память вернется к 0, за исключением загруженной DLL или других вещей, которыеиспользуйте много ОЗУ (много значит несколько ГБ).

Это правда?

Возможно ли еще большое использование ОЗУ, о котором мы можем не знать?(исключая утечки памяти, вызванные неправильным кодом)

1 Ответ

0 голосов
/ 16 мая 2018

Возможно ли еще большое использование ОЗУ, о котором мы можем не знать?

Да.На самом деле GC.Collect() не собирает всю выделенную память.Он собирает только поколения 0,1,2, которые являются «маленькими» объектами.

Примечание: даже не ясно, всегда ли GC.Collect() вызывает полную сборку мусора поколений 0,1 и 2. У людей разные стратегии, чтобы справиться с этим, но я не хочууточните это, поскольку у меня нет окончательного ответа, и он, кажется, зависит от версий .NET.

Есть еще одна куча Куча больших объектов , иногда называемая 4-й кучей(или даже 3-го поколения, которое не является хорошим именем), где размещены все объекты размером> 85000.

Эта куча имеет совершенно другое функционирование.Прочитайте, например:

Кажется, что куча больших объектов зарезервирована процессом (Windows), пока онна самом деле он полон «дыр», которые могут использоваться новыми (большими) объектами и которые менеджер памяти C # считает свободными.

Кучу больших объектов нельзя сжать вручную до .NET 4.5.1.Это происходит только тогда, когда CLR нуждается / хочет этого.

Будет ли CLR часто сжимать LOH или нет, зависит от того, какой сборщик мусора вы используете.Обычно сервер GC , используемый по умолчанию в ASP.NET, не уплотняет LOH.На самом деле это верно для .NET 4.5, но, возможно, развивалось в следующих версиях.Стратегии управления LOH имеют тенденцию развиваться в версиях .NET.Не все детали, которые были объяснены когда-то, остаются верными.

Насколько я знаю, это может быть основной причиной наблюдения нескольких ГБ оставшейся оперативной памяти (которые не являются утечками памяти).Чаще всего это не проблема.Здесь вы найдете намного больше: Когда память, выделенная процессом .NET, возвращается обратно в Windows

...