Явно освобождающая память в c#
function Replace-3rdOctet {
Param(
[string]$GivenIP,
[string]$New3rdOctet
)
$GivenIP -match '(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})' | Out-Null
$Output = "$($matches[1]).$($matches[2]).$New3rdOctet.$($matches[4])"
Return $Output
}
Скопируйте в файл ps1 и поставьте его из командной строки, затем введите
Replace-3rdOctet -GivenIP '100.201.190.150' -New3rdOctet '42'
Вывод: 100.201.42.150
Оттуда вы можете добавить дополнительную обработку ошибок и т. Д. для случайного ввода и т. д.
8 ответов
Байты личного пользования отражают использование памяти процессом. Когда объекты собираются, связанный сегмент памяти может быть освобожден или не освобожден для ОС. CLR управляет памятью на уровне ОС, и, поскольку выделение и освобождение памяти не являются бесплатными, нет причин немедленно освобождать каждую часть памяти, поскольку есть вероятность, что приложение, вероятно, запросит больше памяти позже.
Windows имеет два события доступности памяти. Я ожидаю, что CLR ответит на это. Если памяти достаточно, разумно НЕ запускать сборщик мусора. Поэтому, чтобы убедиться, что вы действительно наблюдаете плохое поведение CLR, повторите этот тест с другим фиктивным приложением, использующим большую кучу памяти.
Вам нужна память обратно? Память доступна, просто не востребована. Вы не должны очищать словарь, удерживать на нем слабую ссылку и позволять среде выполнения делать свою работу.
Если вы хотите действительно глубоко разобраться в происходящем, ознакомьтесь с .NET Профилировщик памяти . Это даст вам представление о том, что именно происходит с вашим объектом, что это за поколение, какая память чем используется, и так далее. :)
, если вы вызываете GC.Collect () он начинает выполнять свою работу, но возвращается немедленно, он не блокируется, поэтому вы не видите его влияния, если вы просто вызовете GC.WaitForPendingFinalizers () после этого, он заблокирует ваше приложение, пока GC.Collect () не завершит свою работу
Скорее всего, у вас есть скрытая ссылка на словарь где-то еще. Таким образом, словарь не собирается, но если вы Clear () его, содержимое будет собрано.
Как уже отмечали другие, принудительное использование GC не рекомендуется. Это может привести к тому, что память будет передана более высоким «поколениям», которые не часто собираются, тем самым тратя впустую больше памяти, чем накоплено в долгосрочной перспективе.
Не знаю по памяти, есть ли Словарь Dispose () или нет, но он обязательно должен иметь Clear () . Вызовите любой из них перед установкой любых ссылок на null .
Затем просто позвольте сборщику мусора делать свою работу. Почти никогда не является хорошей идеей вызывать GC.Collect () самостоятельно, и он может даже не делать то, что вы хотите / требуете / ожидать, и в конечном итоге приведет к снижению производительности. Статический анализ кода (= FxCop) не предупреждает вас с помощью правила надежности CA2001 об этом зря, понимаете? Просто не делайте этого, если вы действительно не знаете, что делаете. И даже тогда не делайте этого. ; -)
Вы уверены, что словарь такой огромный? Isn» Неужели это всего лишь 10 Мб памяти, а остальное занимает ваше приложение? Вопрос, который может вам помочь: использовали ли вы профилировщик, чтобы увидеть, где на самом деле используется память ...?
Как правило, форсировать сборщик мусора - не лучшая идея. Вам действительно нужно, чтобы весь словарь был в памяти?
Изменить:
Чтобы быть справедливым, установка ссылки на null не освобождает память, она назначает ее контейнеру другому адресу, в данном случае null. Согласно MSDN , вызов Clear () делает следующее: «Свойство Count установлено в 0, и ссылки на другие объекты из элементов коллекции также освобождаются. Емкость остается без изменений. "
...
Вы никогда не должны вызывать сборщик мусора. Вы используете управляемые объекты без собственных ресурсов, доверьте сборщику мусора очистку после вас.
Помимо размера вашего словаря, вам не нужно беспокоиться о памяти, память - это не ваша проблема, это сборщики мусора проблема.
Вызов Clear () удалит ссылки на любой содержащийся объект внутри, но емкость остается неизменной.
С технической точки зрения, сбор памяти является дорогостоящим и требует значительных временных затрат. Причина в том, что сборщик мусора не только обрабатывает память кучи и очищает вашу кучу, он также как бы дефрагментирует кучу. Он пытается переместить память в смежные блоки, чтобы ускорить выделение, когда какой-то фрагмент кода делает большой запрос.
ps Насколько велик ваш словарь, в котором вы используете 155 МБ памяти?