По моему опыту кажется, что большинство людей скажет вам, что неразумно принудительно собирать мусор, но в некоторых случаях, когда вы работаете с большими объектами, которые не всегда собираются в поколении 0, но когда память является проблемой, это нормально, чтобы заставить собирать? Есть ли лучшая практика для этого?
Ответы:
Лучше всего не принудительно выполнять сборку мусора.
Согласно MSDN:
«Можно принудительно вызвать сборку мусора, вызвав Collect, но в большинстве случаев этого следует избегать, поскольку это может создать проблемы с производительностью».
Однако, если вы можете надежно протестировать свой код, чтобы подтвердить, что вызов Collect () не окажет отрицательного воздействия, продолжайте ...
Просто постарайтесь убрать предметы, когда они вам больше не нужны. Если у вас есть настраиваемые объекты, обратите внимание на использование оператора using и интерфейса IDisposable.
По этой ссылке есть несколько полезных практических советов по освобождению памяти / сборке мусора и т. Д .:
TargetOfInvocationNullException.
Взгляните на это с другой стороны - эффективнее ли выбросить кухонный мусор, когда мусорное ведро на 10%, или дать ему заполниться, прежде чем вынести его?
Не позволяя ему заполняться, вы тратите время на прогулки к мусорному ведру снаружи и обратно. Это аналогично тому, что происходит при запуске потока GC - все управляемые потоки приостанавливаются во время его работы. И если я не ошибаюсь, поток сборки мусора может быть разделен между несколькими доменами приложений, поэтому сборка мусора влияет на все из них.
Конечно, вы можете столкнуться с ситуацией, когда в ближайшее время вы не будете ничего добавлять в мусорное ведро - скажем, если вы собираетесь в отпуск. Тогда было бы неплохо выкинуть мусор перед выходом на улицу.
Это МОЖЕТ быть один раз, когда принудительный сборщик мусора может помочь - если ваша программа простаивает, используемая память не собирается сборщиком мусора, потому что нет выделений.
Лучше всего в большинстве случаев не принудительно выполнять сборку мусора. (Каждая система, над которой я работал, которая имела принудительную сборку мусора, имела проблемы подчеркивания, которые, если бы они были решены, устранили бы необходимость принудительной сборки мусора и значительно ускорили работу системы.)
Есть несколько случаев, когда вы знаете больше об использовании памяти, чем сборщик мусора. Это маловероятно для многопользовательского приложения или службы, которая одновременно отвечает более чем на один запрос.
Однако в некоторой пакетной обработке вы знаете больше, чем GC. Например, рассмотрим приложение, которое.
Вы можете быть в состоянии сделать случай (после тщательного) тестирования , что вы должны заставить полный сбор мусора после того как вы обрабатывать каждый файл.
Другой случай - это служба, которая просыпается каждые несколько минут для обработки некоторых элементов и не сохраняет никакого состояния во время сна . Тогда может оказаться полезным принудительное выполнение полного сбора перед сном .
Единственный раз, когда я мог бы рассмотреть возможность принудительной коллекции, - это когда я знаю, что много объектов было создано недавно, и очень мало объектов в настоящее время упоминается.
Я бы предпочел иметь API для сборки мусора, когда я мог бы давать ему подсказки об этом типе вещей, не заставляя себя выполнять сборку мусора.
См. Также « Лакомые кусочки выступления Рико Мариани »
Я думаю, что пример, приведенный Рико Мариани, был хорош: может быть уместно запускать сборщик мусора, если есть существенное изменение в состоянии приложения. Например, в редакторе документов может быть нормально запускать сборщик мусора при закрытии документа.
Есть несколько общих правил программирования, которые являются абсолютными. В половине случаев, когда кто-то говорит: «Вы делаете это неправильно», они просто изливают определенную догму. В C раньше было боязнь таких вещей, как самомодифицирующийся код или потоки, на языках GC это заставляет GC или, альтернативно, предотвращает запуск GC.
Как и в случае с большинством руководящих принципов и хороших практических правил (и хороших практик проектирования), в редких случаях имеет смысл обойти установленную норму. Вы должны быть очень уверены, что понимаете дело, что ваш случай действительно требует отказа от общепринятой практики и что вы понимаете риски и побочные эффекты, которые вы можете вызвать. Но есть такие случаи.
Проблемы программирования очень разнообразны и требуют гибкого подхода. Я видел случаи, когда имеет смысл блокировать сборщик мусора на языках со сборкой мусора, и в местах, где имеет смысл запускать его, а не ждать, пока это произойдет естественным образом. В 95% случаев любой из этих факторов может быть признаком неправильного подхода к проблеме. Но 1 раз из 20, вероятно, есть веские основания для этого.
Я научился не пытаться перехитрить сборку мусора. С учетом сказанного, я просто использую usingключевое слово при работе с неуправляемыми ресурсами, такими как файловый ввод-вывод или соединения с базой данных.
Не уверен, что это лучшая практика, но при работе с большим количеством изображений в цикле (т. Е. При создании и удалении большого количества объектов Graphics / Image / Bitmap) я регулярно разрешаю GC.Collect.
Думаю, я где-то читал, что сборщик мусора работает только тогда, когда программа (в основном) простаивает, а не в середине интенсивного цикла, так что это может выглядеть как область, где ручной сбор мусора может иметь смысл.
Один случай, с которым я недавно столкнулся, требовал ручных вызовов, GC.Collect()был при работе с большими объектами C ++, которые были заключены в крошечные управляемые объекты C ++, которые, в свою очередь, были доступны из C #.
Сборщик мусора так и не был вызван, потому что объем используемой управляемой памяти был незначительным, но объем используемой неуправляемой памяти был огромным. Ручной вызов Dispose()объектов потребует, чтобы я отслеживал, когда объекты больше не нужны, тогда как вызов GC.Collect()очистит все объекты, на которые больше не ссылаются ...
GC.AddMemoryPressure (ApproximateSizeOfUnmanagedResource)конструктор, а затем GC.RemoveMemoryPressure(addedSize)- финализатор. Таким образом, сборщик мусора будет запускаться автоматически с учетом размера неуправляемых структур, которые могут быть собраны. stackoverflow.com/questions/1149181/…
Я думаю, что вы уже перечислили лучшие практики, и их НЕ следует использовать, если ДЕЙСТВИТЕЛЬНО не требуется. Я настоятельно рекомендую изучить ваш код более подробно, потенциально используя инструменты профилирования, чтобы сначала ответить на эти вопросы.
Предположим, ваша программа не имеет утечки памяти, объекты накапливаются и не могут быть объединены в сборку мусора в Gen 0, потому что: 1) На них ссылаются в течение длительного времени, поэтому перейдите в Gen1 и Gen2; 2) Это большие объекты (> 80K), поэтому перейдите в LOH (Large Object Heap). И LOH не выполняет уплотнение, как в Gen0, Gen1 и Gen2.
Проверьте счетчик производительности «.NET Memory», и вы увидите, что 1) проблема действительно не является проблемой. Как правило, каждые 10 GC Gen0 запускают 1 GC Gen1, а каждые 10 GC Gen1 запускают 1 GC Gen2. Теоретически GC1 и GC2 никогда не могут быть GC-ed, если нет давления на GC0 (если использование памяти программы действительно подключено). Со мной такого никогда не бывает.
Для проблемы 2) вы можете проверить счетчик производительности «Память .NET», чтобы проверить, не раздувается ли LOH. Если это действительно проблема для вашей проблемы, возможно, вы можете создать пул больших объектов, как предлагается в этом блоге http://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx .
Большие объекты размещаются в LOH (куча больших объектов), а не в поколении 0. Если вы говорите, что они не собираются сборщиком мусора для поколения 0, вы правы. Я считаю, что они собираются только тогда, когда происходит полный цикл сборки мусора (поколения 0, 1 и 2).
При этом, с другой стороны, я считаю, что сборщик мусора будет более агрессивно настраивать и собирать память, когда вы работаете с большими объектами, и давление на память возрастает.
Сложно сказать, собирать или нет и при каких обстоятельствах. Раньше я делал GC.Collect () после удаления диалоговых окон / форм с многочисленными элементами управления и т. Д. (Потому что к тому времени, когда форма и ее элементы управления попадают в поколение 2 из-за создания множества экземпляров бизнес-объектов / загрузки большого количества данных - нет очевидно, большие объекты), но на самом деле не заметил никаких положительных или отрицательных эффектов в долгосрочной перспективе.
Я хотел бы добавить, что: вызов GC.Collect () (+ WaitForPendingFinalizers ()) - это одна часть истории. Как справедливо упоминалось другими, GC.COllect () является недетерминированной коллекцией и оставлено на усмотрение самого GC (CLR). Даже если вы добавите вызов WaitForPendingFinalizers, он не может быть детерминированным. Возьмите код из этой ссылки msdn и запустите код с итерацией цикла объекта как 1 или 2. Вы обнаружите, что означает недетерминированный (установите точку останова в деструкторе объекта). Точнее, деструктор не вызывается, когда Wait .. () содержит только 1 (или 2) устаревших объекта. [Треб. Цитирования]
Если ваш код имеет дело с неуправляемыми ресурсами (например, дескрипторами внешних файлов), вы должны реализовать деструкторы (или финализаторы).
Вот интересный пример:
Примечание . Если вы уже пробовали приведенный выше пример из MSDN, следующий код очистит эфир.
class Program
{
static void Main(string[] args)
{
SomePublisher publisher = new SomePublisher();
for (int i = 0; i < 10; i++)
{
SomeSubscriber subscriber = new SomeSubscriber(publisher);
subscriber = null;
}
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine(SomeSubscriber.Count.ToString());
Console.ReadLine();
}
}
public class SomePublisher
{
public event EventHandler SomeEvent;
}
public class SomeSubscriber
{
public static int Count;
public SomeSubscriber(SomePublisher publisher)
{
publisher.SomeEvent += new EventHandler(publisher_SomeEvent);
}
~SomeSubscriber()
{
SomeSubscriber.Count++;
}
private void publisher_SomeEvent(object sender, EventArgs e)
{
// TODO: something
string stub = "";
}
}Я предлагаю сначала проанализировать, каким может быть результат, а затем запустить, а затем прочитать причину ниже:
{Деструктор неявно вызывается только после завершения программы. } Чтобы детерминированно очистить объект, необходимо реализовать IDisposable и сделать явный вызов Dispose (). В этом суть! :)
Еще одна вещь: явный запуск GC Collect НЕ может улучшить производительность вашей программы. Вполне возможно сделать хуже.
.NET GC хорошо спроектирован и настроен для адаптации, что означает, что он может регулировать порог GC0 / 1/2 в соответствии с «привычкой» использования памяти вашей программой. Таким образом, через некоторое время он будет адаптирован к вашей программе. Как только вы явно вызовете GC.Collect, пороги будут сброшены! И .NET придется потратить время, чтобы снова адаптироваться к «привычке» вашей программы.
Я предлагаю всегда доверять .NET GC. Любые проблемы с памятью обнаруживаются, проверяйте счетчик производительности ".NET Memory" и диагностируйте мой собственный код.
Не уверен, что это лучшая практика ...
Предложение: не выполняйте это или что-либо еще, если не уверены. Переоценивайте, когда факты известны, а затем выполняйте тесты производительности до / после для проверки.
Однако, если вы можете надежно протестировать свой код, чтобы подтвердить, что вызов Collect () не окажет отрицательного воздействия, продолжайте ...
ИМХО, это похоже на высказывание «Если вы можете доказать, что ваша программа никогда не будет содержать ошибок в будущем, тогда вперед ...»
Если серьезно, то принудительный сборщик мусора полезен для целей отладки / тестирования. Если вы чувствуете, что вам нужно сделать это в любое другое время, то либо вы ошибаетесь, либо ваша программа построена неправильно. В любом случае решение не заставляет GC ...