Сборка мусора не уменьшает текущее использование памяти - в режиме выпуска. Почему?

Сборщик мусора не гарантированно запускается при вызове Collect (). Он просто помечает объект для сбора. При следующем запуске GC он «соберет» помеченный объект.

В .NET нет способа заставить сборщик мусора собирать данные в определенный момент времени - если вам нужна эта функция, вам нужно будет перейти к собственному коду.

Вызов GC.Collect () - это всего лишь запрос на сбор мусора, а не заказ, поэтому среда CLR может проигнорировать запрос, если сочтет нужным.

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

Для многих распределителей памяти (со сборкой мусора или без нее) нормально "накапливать" освобожденную память, а не возвращать ее ОС, потому что во многих ситуациях только что освобожденная память будет запрашиваться снова, и это быстрее. чтобы сохранить его в процессе, а не возвращать его и снова и снова просить ОС (возвращение и т. д. также требует дополнительных усилий из-за проблем с выравниванием страниц и т.п.).

Как вы упомянули, в одноразовом приложении это не проблема. Когда у меня есть долго работающее приложение, которое, как я знаю, будет временным требованием для большого количества памяти, один из подходов, которые я использую, - это создать подпроцесс для выполнения требующих памяти вещей, поскольку, когда этот процесс завершает работу ОС вернет память. Это проще в системах Unix (просто форк), но не так уж плохо и в Windows, если это необходимо.

Есть выход. Я нашел эту статью, она на испанском языке, уверен, что вы понимаете код, она работает, я протестировал [http://www.nerdcoder.com/c-net-forzar-liberacion-de-memoria-de-nuestras-aplicaciones/%5d%5b1%5d

[DllImport("kernel32.dll", EntryPoint = "SetProcessWorkingSetSize", ExactSpelling = true, CharSet = CharSet.Ansi, SetLastError = true)]
private static extern int SetProcessWorkingSetSize(IntPtr process, int minimumWorkingSetSize, int maximumWorkingSetSize);
public static void alzheimer()
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
    SetProcessWorkingSetSize(System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1);
}

Возможно, ваши объекты все еще как-то укоренились. Вы можете попробовать использовать профилировщик памяти, чтобы узнать, так ли это. Обычно для этого я рекомендую .NET Memory Profiler от SciTech, но Red-Gate также имеет достойный профилировщик памяти. У SciTech и Red-Gate есть пробные версии. Также возможно использование WinDBG с SOS.

здесь.

Не забывайте, что CLR в конечном итоге использует базовый диспетчер памяти в ядре Windows, у которого могут быть свои собственные политики относительно того, когда освобождать память. Например, если используемая вами память поступает из пула, она может быть просто возвращена в пул, а не освобождена, когда вы освобождаете ее на уровне пользователя. Поэтому вполне возможно, что может быть (и, вероятно, будет) несоответствие между объемом памяти, который хранится в вашем приложении, и объемом памяти, выделенной процессу.

Метод Collect не гарантирует освобождение всей недоступной памяти.

чтобы заставить GC.Collect выполнять сбор, назовите его так: GC.Collect (2); это означает, что вы просите GC выполнить полную блокировку GC для всей кучи, 2 означает поколение 2 вашей кучи.

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

Реализует ли какой-либо из объектов, используемых в вашем цикле, IDisposable?