GC.Collect ()

Хорошо, я прочитал несколько тем об этом, но здесь это идет. Давайте представим, что у меня есть приложение, в котором время от времени я нажимаю кнопку, в течение нескольких минут происходит много вещей, а затем она простаивает еще час или, может быть, всего 1 минута , Разве после того, как все это закончилось, хорошая ситуация для вызова GC.Collect? Я имею в виду, я знаю, что именно в этот момент я не буду использовать свое приложение, и GC не может догадаться об этом.

Ответы на вопрос(7)

как уже упоминалось в других публикациях, GC знает, когда начинать сбор лучше, чем вы, тот факт, что в вашем приложении не нажимают кнопки, не означает, что пора начинать очистку, GC делает какие-то блокировки при перемещении объектов. , так что это может привести к низкой производительности, если вы будете злоупотреблять GC.Collect

GC.Collect()Вы должны знать подробности о конкретном сборщике, связанном со средой выполнения, а также подробную информацию о слабом месте, которое вы можете устранить с помощью сбора.

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

 devoured elysium19 июл. 2009 г., 06:08
Как это может оказать разрушительное влияние на производительность моей программы? Я бы сказал, что это окажет разрушительное влияние на производительность моей программы, если случайно это произойдет именно во время работы моего процесса, а не тогда, когда я знаю, что он будет бездействовать.
 19 июл. 2009 г., 06:44
Это полностью зависит от реализацииGC.Collect() и основные технологии. Например, управляемая система может использовать межпроцессный общий распределитель, гдеGC.Collect() звонок останавливает все приложения вместо одного. Где-то может быть место, где можно позвонитьGC.Collect(), но если вы знаете это место, то вам, вероятно, не нужно задавать нам какие-либо вопросы по этому поводу. :)
 devoured elysium19 июл. 2009 г., 06:02
Моя точка зрения в основном такова: нет ничего плохого, что может случиться, если мы используем GC.Collect (), верно? Если в этом нет ничего плохого, то нечего терять, если мы сделаем это сейчас, когда знаем, что, по крайней мере, на мгновение наш процесс будет бездействовать, вместо того, чтобы делать это в какой-то случайный момент. Или что-то здесь, что мне не хватает? Спасибо
 19 июл. 2009 г., 06:06
Да, вызов GC.Collect () может оказать разрушительное влияние на производительность вашей программы. Или это ничего не может сделать. Важно помнить: в отличие от ранних дней Java, современные GCsvery хорошо справляются со своей работой иalmost never виновник в проблемах производительности приложений. Фактически, .NET и Java GC быстрее, чем многие реализации C / C ++.
Решение Вопроса

что несколько человек были крайне недовольны тем, что не рекомендуют звонить в GC.Collect.

GC.Collect существует по причине, вот моя рекомендация о том, когда и зачем звонить в GC.Collect.

In General, don't worry about calling it, GC tunes itself very well and will do the right thing.

Sometimes, you end up in situation where you know for sure that this is the right time to call it, the situation you described above is exactly the right time to call it, in fact Asp.Net calls GC.Collect at certain points that are similar to what you described.

The GC is smart about calling GC.Collect, if you called GC.Collect, the GC can override your decision and still doesn't collect ( you have to set a flag when you call GC.Collect to choose this behavior), this is the recommended way of calling GC.Collect, since you are still letting the GC decides if it is a good time to collect.

Don't take my recommendation is a general statement for calling GC.Collect, you should always avoid calling it, unless you REALLY sure you need to call it, situation like the one you described is exactly why GC.Collect is there.

The benefit you will get from calling it is freeing the garbage quickly, generally you will care about this situation if

You are in low memory situation and want to be eager about collection, if you are in low memory situation, the GC will be aggressive anyway and will kick in automatically if the memory pressure is high on the machine If you want to avoid getting in low memory situation and you want to collect eagerly.

Надеюсь это поможет.
Спасибо

 devoured elysium21 июл. 2009 г., 06:50
Ах, наконец ....
 10 окт. 2015 г., 11:32
Ваш второй пункт неверен. По умолчанию используется принудительный режим
 21 июл. 2009 г., 07:03
:) как я уже говорил, не принимайте мою рекомендацию в качестве общего правила, это исключительный случай; это просто случилось, чтобы соответствовать вашему делу :)

GC.Collect().

В вашем случае нет абсолютно никаких причин называть это. Если вы не работаете в течение часа, GCwill делать свои коллекции.

 19 июл. 2009 г., 06:09
Когда вы вызываете GC.Collect (), любые объекты, которые не собраны, продвигаются так, чтобы они жили дольше в другом месте. Создайте в Google "сборку мусора поколений". Как бы то ни было, сейчас у вашего приложения не будет перфектного хита, это может повлиять на него позже.
 19 июл. 2009 г., 05:58
+1. вызов GC.Collect () может фактически продлить время жизни объекта
 devoured elysium19 июл. 2009 г., 05:59
Что вы имеете в виду, продвигая срок службы объекта?
 devoured elysium19 июл. 2009 г., 05:58
Да, но это может быть в следующую минуту. Но только когда я заканчиваю свою обработку, я знаю, что в этот момент не будет никакого снижения производительности, если я потрачу пару секунд на выполнение GC.Collect ().
 devoured elysium19 июл. 2009 г., 06:13
Ах да, я тоже об этом читал. Я не принимал это во внимание, и это действительно хороший момент.

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

Если вы пытаетесь оптимизировать время, знаете ли вы, сколько времени GC тратит на сбор объектов в вашем приложении? В настольных операционных системах (XP, Vista и т. Д.) CLR использует параллельный GC и может работать без приостановки всех потоков в приложении на время сбора.

Явный вызов GC.Collect не рекомендуется, потому что

It throws the CLR GC Tuning algorithm out of gear. The tuner determines when to trigger a GC automatically, and forcing a manual GC messes with its calculations.

By forcing a collection manually, you can end up promoting objects up a generation - objects which might have been collected in the next GC ( if they were "orphaned" before the GC decided to kick in).

Вам может показаться интересным, что .NET 4.0,Механизм уведомления GC был введен для таких сценариев.

 devoured elysium19 июл. 2009 г., 07:03
Это только создает у меня впечатление, что люди считают, что теперь GC будет лучше, чем мы, программисты, работать с нашей программой. Теперь я могу предположить, что мой процесс происходит каждый раз, когда мой компьютер простаивает 2 минуты, и мне трудно поверить, что теперь GC сделает то же самое. Весь аргумент о том, что лучшее время для GC по сравнению с ручным GC, кажется не основательным, только это.
 devoured elysium19 июл. 2009 г., 07:04
редактировать: знать * в некоторых местах.
 19 июл. 2009 г., 08:48
Что ж, если вы создаете каждый отдельный объект в куче и можете рассчитать все возможные варианты управления в своем коде, то да, вы будете знать лучше, чем сборщик. Даже в этом случае сборщик мусора может принимать во внимание такие вещи, как доступная физическая память - он может решить отложить его, например, в случае интенсивной подкачки. Это те вещи, которые находятся вне вашего контроля. Код является статичным, и, за исключением очень особых случаев, я думаю, что было бы очень трудно заранее предсказать условия времени выполнения, преобладающие во время GC.Collect.
 devoured elysium19 июл. 2009 г., 06:31
Спасибо за ответ. Я не уверен, что получил следующее замечание: «Знаете ли вы, сколько времени GC тратит на сбор объектов в вашем приложении? В настольных операционных системах (XP, Vista и т. Д.) CLR использует одновременный сборщик мусора и может работать без приостановки всех потоков в приложении на время сбора. & Quot ;. Из того, что я прочитал, похоже, что сборка GC довольно быстрая (не должна занимать больше времени, чем ошибка страницы для поколения 0). Что касается твоей точки зрения, t 2), ну, это не кажется хорошим аргументом. То же самое относится и к тому, когда вы делаете обычный GC.
 19 июл. 2009 г., 06:47
Если сбор GC довольно быстрый, зачем называть его вручную, чтобы сэкономить время? Что касается второго пункта, конечно, то же самое происходит, когда происходит регулярный сборщик мусора, но затем сборщик мусора решает, когда его запускать, что снова определяется алгоритмом настройки сборщика мусора. Он может выяснить, что существует способ, которым ваше приложение выделяет объекты, и использовать эти знания для запуска GC в наилучшее возможное время с памятью - в этом случае немного позже. Это будет собирать больше объектов и продвигать меньше.

только если вы пытаетесь выделить новую память. Если у вас не хватает памяти, вы получаете повышение производительности на 0% от вызова GC. Вы должны иметь довольно безумно ресурсоемкое приложение, чтобы даже приблизиться к пределам оперативной памяти на современных компьютерах.

Если ваша программа имеет много внешних ресурсов (таких как файлы или ссылки COM / DCOM), вы, возможно, захотите вызвать GC.

Если обращение в ГК даст вам душевное спокойствие, тогда продолжайте. Вероятно, это не поможет, но, безусловно, не повредит.

 14 мар. 2011 г., 16:36
Um. Люди запускают программное обеспечение на старых машинах. Когда я помогаю людям очистить свои машины, чтобы они работали лучше, я часто нахожу программное обеспечение, использующее 50-100 МБ рабочего набора, просто так, чтобы оно могло бездельничать в ожидании интернет-телефонного звонка или чего-то еще смешного. На 1 ГБ машине эти вещи складываются быстро!

llect до того, как вы создадите прототип или создадите приложение и протестируете его производительность. ГК обычно очень хорошо собирает память в подходящее время. Он, безусловно, будет запускать коллекцию во время простоя вашего приложения, особенно если в системе присутствует нехватка памяти.

Гораздо важнее, что вы будете следовать хорошим правилам распределения GC для поколений (небольшие объекты, короткое использование и т. Д.) И, скорее всего, получите желаемые характеристики производительности. Если у вас все еще нет нужной вам производительности, после профилирования и хорошего дизайна вы можете подумать о GC.Collect как о решении.

 21 июл. 2009 г., 07:00
Очень содержательный, но лаконичный
 19 июл. 2009 г., 06:40
+1. Хорошее объяснениеwhy GC.Collect () почти всегда не нужен.
 devoured elysium19 июл. 2009 г., 05:59
Ладно, это кажется более разумным ответом, чем целые "нет сборников gc". я вижу всплывающее окно везде.

Ваш ответ на вопрос