GC.Collect ()
С ps или подобные инструменты Вы только выделите страницы объема памяти тем процессом. Это число корректно, но:
-
не отражает фактический объем памяти, используемый приложением, только объем памяти, зарезервированный для него
-
, может вводить в заблуждение, если страницами поделятся, например, несколько потоков или при помощи динамически подключаемых библиотек
, Если Вы действительно хотите знать, какой объем памяти Ваше приложение на самом деле использует, необходимо выполнить его в профилировщике. Например, valgrind может дать Вам понимание об объеме памяти, используемом, и, что еще более важно, о возможных утечках памяти в Вашей программе. Инструмент профилировщика "кучи" valgrind называют 'горным массивом':
Горный массив является профилировщиком "кучи". Это выполняет подробное профилирование "кучи" путем взятия обычных снимков "кучи" программы. Это производит график, показывающий использование "кучи" со временем, включая информацию, о которой части программы ответственны за большинство выделений памяти. График добавляется текстом или файлом HTML, который включает больше информации для определения, где большая часть памяти выделяется. Горный массив запускает программы о 20x медленнее, чем нормальный.
, Как объяснено в valgrind документация , необходимо запустить программу через valgrind:
valgrind --tool=massif
Горный массив пишет дамп снимков использования памяти (например, massif.out.12345). Они обеспечивают, (1) временная шкала использования памяти, (2) для каждого снимка, записи того, где в Вашей памяти программ был выделен. Большой графический инструмент для анализа этих файлов горный-массив-visualizer . Но я нашел ms_print, основанный на простом тексте инструмент поставленный с valgrind, уже чтобы очень помочь.
Для нахождения утечек памяти используйте (значение по умолчанию) memcheck инструмент valgrind.
7 ответов
Я вижу, что некоторые люди зашли в крайность, не рекомендуя вызывать GC. Collect.
GC.Collect существует по какой-то причине, вот моя рекомендация, когда и почему вызывать GC.Collect.
В общем, не беспокойтесь о его вызове, GC сам настраивается очень хорошо и подойдет
Иногда вы попадаете в ситуацию, когда точно знаете, что сейчас самое подходящее время для этого, описанная выше ситуация - как раз подходящее время для этого, на самом деле Asp.Net вызывает GC .Collect в определенных точках, которые похожи на то, что вы описали.
GC разумно вызывает GC.Collect, Спасибо
Почти всегда преждевременная оптимизация - беспокоиться о вызове GC.Collect до того, как вы создадите прототип или построите приложение и проверите его производительность. GC обычно очень хорошо собирает память в нужное время. Он определенно будет запускать сбор данных, пока ваше приложение простаивает, особенно если в системе есть нехватка памяти.
Гораздо важнее, чтобы вы следовали хорошей практике распределения GC поколений (небольшие объекты, кратковременное использование и т. Д.), И вы, вероятно, получите желаемые характеристики производительности. Если у вас по-прежнему нет необходимой производительности, после профилирования и хорошего дизайна вы можете подумать о GC.Collect как о решении.
Практически никогда не бывает веских причин для вызова GC.Collect () .
В вашем случае называть это абсолютно незачем. Если вы простаиваете в течение часа, сборщик мусора будет выполнять сбор данных.
Надеюсь, вы знаете, что вызов GC.Collect не вызывает сбора большего (или меньшего) количества объектов.
Если вы пытаетесь оптимизировать время, знаете ли вы, сколько времени требуется GC для сбора объектов в вашем приложении? В операционных системах настольных ПК (XP, Vista и т. Д.) Среда CLR использует параллельный сборщик мусора и может работать без приостановки всех потоков в приложении на время сбора.
Явный вызов GC.Collect не рекомендуется, поскольку
Вызывает сбой алгоритм настройки CLR GC. Тюнер определяет, когда запускать сборщик мусора автоматически, и принудительный запуск сборщика мусора приводит к путанице в его вычислениях.
Принудительно принудительно собирая сборку, вы можете в конечном итоге продвигать объекты до поколения - объекты, которые могли быть собраны в следующем сборщике если бы они были "осиротевшими"
Чтобы знать, когда вызывать GC.Collect () , вам нужно знать детали конкретного сборщика, задействованного во время выполнения, а также подробную информацию о слабых местах. что вы можете решить с помощью коллекции.
Другими словами, если вы действительно знаете, когда вам нужно вызвать GC.Collect () , и это не то, что вы сделали плохо в другом коде, тогда вы, вероятно, работаете с Внутренними компонентами CLR и можете просто решить проблему.
Обычно сборщик мусора вызывается только в том случае, если вы пытаетесь выделить новую память. Если у вас не закончится память, вы получите повышение производительности на 0% от вызова GC. У вас должно быть безумно ресурсоемкое приложение, чтобы хотя бы приблизиться к пределу оперативной памяти на современных компьютерах.
Если у вашей программы много внешних ресурсов (например, файлов или ссылок COM / DCOM), вы, возможно, захотите вызвать GC.
Если вызов GC даст вам душевное спокойствие, продолжайте. Скорее всего, это не поможет, но точно не повредит.
Да, как упоминалось в других сообщениях, GC знает, когда начать сбор лучше, чем вы, фактор, что в вашем приложении не нажимаются кнопки, не означает, что пора начинать очистку, GC выполняет какие-то блокировки при перемещении объектов, поэтому это может снизить производительность, если вы злоупотребляете GC.Collect