Причины, по которым не следует вызывать сборщик мусора напрямую

Question

В настоящее время я пишу статью для своей компании о том, как избежать вызова сборщика мусора непосредственно из кода (например, при игре с COM-объектами).

Я знаю, что это плохая практика,и следует рассматривать только в очень редких случаях, но я не могу найти способ сказать, почему этого следует избегать.И я не хочу полагаться на принцип «ГК умнее тебя» (даже если это правда :-))

Так что вы можете рассказать мне несколько подсказок о том, почему вы думаете, что следует избегатьвызвать сборщик мусора напрямую?(влияние на производительность?) Или, может быть, если у вас есть ссылки на эту конкретную тему, они будут очень полезны.

Заранее спасибо!

Редактировать: Все предоставленные вами ответы действительно полезны,Поскольку я не могу проверить всех (или могу?), Что мне делать?Создать сообщество вики?

Answer 1

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

Учитывая, что в такой ситуации легче стать лучшепроизводительность, мне кажется, ежу понятно!

NB.При игре с COM-объектами прямой вызов GC вряд ли решит вашу проблему.Если COM-объекты торчат, то у них ненулевое количество ссылок, и никакое количество дополнительных вызовов GC не исправит это.

Answer 2

Обычный аргумент производительности работает так:

Поколения GC быстры, потому что полагаются на эвристику, согласно которой многие выделенные объекты являются недолговечными (объект «жив», пока он достижим; цель GC - обнаруживать «мертвые» объекты и возвращать их объем памяти). Это означает, что объекты могут накапливаться в специальной области («молодое поколение»); GC запускается, когда эта область заполнена, и очищает живые объекты, перемещая их («физически») в старое поколение. В большинстве поколений GC эта операция подразумевает паузу («остановка мира»), которая терпима, потому что она короткая (молодое поколение имеет ограниченный размер). Тот факт, что мир приостанавливается во время сбора данных молодого поколения, позволяет эффективно обрабатывать молодые объекты (а именно чтение или запись ссылки в полях молодого объекта представляет собой простой доступ к памяти без необходимости учитывать параллельный доступ из потока GC или инкрементная метка и развертка).

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

Запуск ГХ вручную аналогичен сокращению молодого поколения. Это означает, что все больше молодых объектов будут продвигаться к старому поколению, увеличивая тем самым стоимость сбора молодого поколения (нужно отбирать больше объектов) и стоимость сбора старого поколения (больше старые объекты для обработки).

Answer 3

Если вам нужно вызвать GarbageCollector, чтобы убедиться, что COM-объекты освобождены, это, вероятно, является хорошим признаком того, что ваши разработчики не вызывают Dispose и / или не используют using, когда должны. Таким образом, один из аргументов может заключаться в том, что он будет просто скрывать плохой код, и вместо него будет лучше исправить плохой код.

Answer 4

Это влияет на производительность, так как все потоки должны быть остановлены для того, чтобы выполнить сбор.После этого ему нужно определить, что используется, а что нет, и так далее ...

Все, что требует времени и сборщик мусора, будет работать только тогда, когда определит, что выгода больше, чем вред.* Когда вы звоните в GC самостоятельно, вы, скорее всего, будете звонить слишком часто, и это увеличит время, проведенное в GC, и сократит время, затрачиваемое на вашу программу.