Причины, почему не нужно называть сборщик "мусора" непосредственно
Я в настоящее время пишу работу для своей компании, о том, как постараться не называть сборщик "мусора" непосредственно из кода (при проигрывании с COM-объектами, например).
Я знаю, что это - плохая практика и должно быть только рассмотрено в очень редких случаях, но я, может казаться, не нахожу способ сказать, почему этого нужно избежать. И я не хочу полагаться "на G.C., более умно, чем Вы" принцип (даже если это - истина :-))
Таким образом, можно ли сказать мне некоторые подсказки о том, почему Вы думаете, что нужно постараться не называть сборщик "мусора" непосредственно? (влияние производительности?) Или возможно если бы у Вас есть ссылки об этой конкретной теме, они были бы очень полезны.
Заранее спасибо!
Править: Все aswers, которые Вы обеспечили до сих пор, действительно полезны. Поскольку я не могу проверить всех (или могу я?), что я должен сделать? Сделать общественную Wiki?
4 ответа
Обычный аргумент производительности выглядит следующим образом:
Сборка мусора поколений работает быстро, потому что они полагаются на эвристику, согласно которой многие выделенные объекты являются недолговечными (объект остается «живым» до тех пор, пока он существует. достижима; цель сборщика мусора - обнаруживать «мертвые» объекты и восстанавливать их память). Это означает, что предметы могут накапливаться в особой зоне («молодое поколение»); GC запускается, когда эта область заполнена, и очищает живые объекты, перемещая их («физически») в старое поколение. В большинстве сборок поколений эта операция подразумевает паузу («остановка мира»), которая допустима, потому что она короткая (молодое поколение имеет ограниченный размер). Тот факт, что мир приостанавливается во время сбора молодого поколения, позволяет эффективно обрабатывать молодые объекты (а именно, чтение или запись ссылки в полях молодого объекта - это простой доступ к памяти без необходимости учитывать одновременный доступ из потока GC. или инкрементная отметка и развертка).
Молодое поколение с коллекцией, управляемой, как я описал выше, эффективно, потому что, когда молодое поколение собирается, большинство объектов в нем уже мертвы, поэтому они не несут дополнительных затрат. Оптимальный размер молодого поколения - это компромисс между наихудшим случаем (все молодые объекты живы, что подразумевает максимальное время паузы) и средней эффективностью (когда молодое поколение больше, большее количество объектов успевает умереть до того, как collection, что снижает среднюю стоимость GC).
Запуск сборщика мусора вручную аналогичен укорачиванию молодого поколения. Это означает, что больше молодых объектов будет продвигаться к старому поколению, таким образом увеличивая стоимость сбора молодого поколения (необходимо собрать больше объектов) и стоимость сбора старого поколения (подробнее старые предметы в обращении).
Основная причина заключается в том, что программа, которая тратит больше времени, чем необходимо на выполнение полных сборов в GC, будет медленнее, чем должна быть.
Учитывая, что в этой ситуации легче добиться лучших результатов, мне кажется, что это не проблема!
NB. При игре с COM-объектами прямой вызов GC вряд ли решит вашу проблему. Если COM-объекты находятся поблизости, значит, у них ненулевое количество ссылок, и никакие дополнительные вызовы GC не исправят это.
Это влияет на производительность, поскольку все потоки должны быть остановлены для выполнения сбора. После этого ему нужно определить, что используется, а что нет, и так далее ...
Все это требует времени, и сборщик мусора будет работать только тогда, когда он определит, что польза больше, чем вред.
Когда вы вызываете GC самостоятельно, вы, скорее всего, просто будете вызывать его слишком часто, и это увеличит время, затрачиваемое на GC, и уменьшит время, затрачиваемое на вашу программу.
Если вам нужно вызвать GarbageCollector, чтобы убедиться, что COM-объекты освобождены, это, вероятно, хороший знак того, что ваши разработчики не вызывают Dispose и / или не делают этого. t используйте , используя , когда они должны. Таким образом, одним из аргументов может быть то, что он просто скрывает плохой код, и вместо этого было бы лучше исправить плохой код.