Каков риск вызова GC.Collect ()? [Дубликат]

Я научился не пытаться перехитрить сбор мусора. С учетом сказанного я просто придерживаюсь использования ключевого слова using при работе с неуправляемыми ресурсами, такими как подключение к файлу ввода-вывода или базы данных.

Я думаю, что вы уже перечислили лучшую практику, и это НЕ использовать, если это НЕОБХОДИМО. Я бы настоятельно рекомендовал более детально проанализировать ваш код, используя инструменты профилирования, если это необходимо для ответа на эти вопросы.

1. У вас есть что-то в своем коде, который объявляет элементы в большем объеме, чем
2. Является ли использование памяти действительно слишком высоким
3. Сравните производительность до и после использования GC.Collect (), чтобы увидеть, действительно ли это помогает.

Еще одна вещь: запуск GC Collect явно не может улучшить производительность вашей программы.

. NET GC хорошо спроектирован и настроен как адаптивный, что означает, что он может настроить порог GC0 / 1/2 в соответствии с «привычкой» вашей программной памяти Применение. Таким образом, он будет адаптирован к вашей программе через некоторое время. Когда вы вызовете GC.Collect явно, пороговые значения будут сброшены! И .NET должен потратить время, чтобы снова адаптироваться к привычке вашей программы.

Мое предложение всегда является надежным .NET GC. Любые проблемы с памятью, проверьте счетчик производительности «.NET Memory» и диагностируйте мой собственный код.

Однако, если вы можете надежно протестировать свой код, чтобы подтвердить, что вызов Collect () не будет иметь отрицательного воздействия, тогда продолжайте ...

IMHO, это аналогично высказыванию «Если вы можете доказать, что ваша программа никогда не будет иметь никаких ошибок в будущем, тогда идите вперед ...»

По всей серьезности принудительное использование GC полезно для целей отладки / тестирования. Если вы чувствуете, что вам нужно делать это в любое другое время, то либо вы ошибаетесь, либо ваша программа была построена неправильно. В любом случае, решение не заставляет GC ...

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

Как и в случае с большинством руководств и хороших эмпирических правил (и хороших методов проектирования), есть редкие случаи, когда имеет смысл работать по установленной норме. Вы должны быть уверены, что понимаете дело, что ваш случай действительно требует отмены обычной практики и что вы понимаете риски и побочные эффекты, которые вы можете вызвать. Но есть такие случаи.

Проблемы программирования очень разнообразны и требуют гибкого подхода. Я видел случаи, когда имеет смысл блокировать GC в собранных мусором языках и местах, где имеет смысл запускать его, а не ждать, когда это произойдет естественным образом. 95% времени, любой из них был бы признаком того, что не подошел к проблеме правильно. Но 1 раз в 20, вероятно, для этого есть действительный случай.

Не уверен, что это лучшая практика ...

Предложение: не реализуйте это или что-нибудь, когда вы не уверены. Переоценивайте, когда факты известны, затем выполните до / после проверок производительности.

Я хотел бы добавить, что: вызов GC.Collect () (+ WaitForPendingFinalizers ()) является частью истории. Как справедливо упоминается другими, GC.COllect () является недетерминированным набором и остается на усмотрение самого GC (CLR). Даже если вы добавите вызов WaitForPendingFinalizers, это может быть не детерминированным. Возьмите код из этой ссылки msdn и запустите код с итерацией цикла объекта как 1 или 2. Вы найдете то, что не является детерминированным средством (установите точку прерывания в деструкторе объекта). Точно так же деструктор не вызывается, когда Wait .. () имеет только 1 (или 2) затяжные объекты. [Citation reqd.]

Если ваш код имеет дело с неуправляемыми ресурсами (например: внешний файл дескрипторы).

Вот интересный пример:

Примечание. Если вы уже пробовали пример из 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 (). В этом суть! :)