Утечка памяти при использовании таймеров

Question

Утечка памяти при использовании таймеров

1

У меня есть фрагмент кода, который профайлер Ants указывает на то, что это вызывает утечку памяти. Я отслеживал приложение в течение 1 недели, но память, кажется, растет и не возвращается. Я немного обеспокоен приведенным ниже кодом.

      public void printXML(XmlDocument doc)
        {
            //System.Threading.Timer timer = null;
            XmlWriterSettings settings = new XmlWriterSettings { Encoding = Encoding.UTF8, Indent = true };
            new System.Threading.Timer((_) =>
            {
                using (var writer = XmlWriter.Create(_folderDestination, settings))
                {
                    //                Task.Delay(15000).ContinueWith(_ => doc.Save(writer));                
                    doc.Save(writer);
                }
            }).Change(15000, -1);

        }

Каждый раз, когда printXML метод printXML он записывает doc в _folderDestination через период 15 секунд. Этого я хочу достичь. Но вышеприведенный код, похоже, содержит утечку памяти, и память больше не возвращается. Поэтому, если кто-то может помочь его оптимизировать, было бы здорово.

user726720 06 нояб. 2014, в 08:17

Источник

3

Примечание: Ваш Timer имеет право на сборку мусора. Вам нужно сохранить ссылку на таймер, чтобы он не был GC'd.
Sriram Sakthivel 06 нояб. 2014, в 06:31
0

Мне любопытно, почему вы прокомментировали решение с Task.Delay ? Как упомянул @SriramSakthivel, ваш таймер будет собран GC, и ваш код никогда не будет выполнен. Task.Delay здесь намного проще.
Dennis 06 нояб. 2014, в 06:47
0

@Dennis: код выполняется, и у меня есть эффект 15сек, но меня больше беспокоит проблема с памятью
user726720 06 нояб. 2014, в 06:52
0

@ user726720: этот код может выполняться в течение сеанса отладчика, также он может выполняться без отладчика, но вероятность его выполнения в конфигурации выпуска близка к 0.
Dennis 06 нояб. 2014, в 06:54
0

@SriramSakthivel: Я верю, что сборка мусора здесь не проблема, пожалуйста, исправьте меня, если я ошибаюсь (что я делаю большую часть времени, смеется), потому что код действительно выполняется. Так что таймер должен быть GC'ed после выполнения. Если это так, новый объект помещается в память при следующем printXML . Как я могу предотвратить образование новых объектов?
user726720 06 нояб. 2014, в 06:57
0

@Dennis: я пробовал это в конфигурации релиза и в производстве уже довольно давно. Я совершенно прав, это выполняется.
user726720 06 нояб. 2014, в 06:58
0

@ user726720: вы не можете предсказать, когда произойдет сборка мусора. Этот код может работать, но в конечном итоге он потерпит неудачу, потому что таймер будет собран до его истечения.
Dennis 06 нояб. 2014, в 07:03
0

@ user726720 Мой комментарий не о проблеме с памятью. Честно говоря, нет информации, чтобы ответить на этот вопрос. Будет лучше, если вы напишите mvce, чтобы воспроизвести проблему. Мой комментарий выше говорит о том, что в вашем коде есть проблема, которая может быть неочевидной, которая работает сейчас, но это не значит, что она продолжит работать. Отослать это
Sriram Sakthivel 06 нояб. 2014, в 07:04
0

Время цели использования таймера здесь состоит в том, чтобы задержать выполнение, и нет элегантного способа избавиться от него (что приводит к утечке памяти). Может быть, проще просто начать новый поток, который спит на х секунд. Или используйте один и тот же таймер, если два printXML не будут запущены одновременно.
Vince 06 нояб. 2014, в 07:29
0

@ Vince У меня одновременно работают 7 разных потоков FSW, которые могут вызывать printXML в разное время.
user726720 06 нояб. 2014, в 07:31
0

@ user726720 Как насчет создания новой темы? Смотрите мой отредактированный ответ.
Vince 06 нояб. 2014, в 07:49

Показать ещё 9 комментариев

Теги:

c#

timer

.net

1 ответ

Ещё вопросы

Примечание: Ваш Timer имеет право на сборку мусора. Вам нужно сохранить ссылку на таймер, чтобы он не был GC'd.
Мне любопытно, почему вы прокомментировали решение с Task.Delay ? Как упомянул @SriramSakthivel, ваш таймер будет собран GC, и ваш код никогда не будет выполнен. Task.Delay здесь намного проще.
@Dennis: код выполняется, и у меня есть эффект 15сек, но меня больше беспокоит проблема с памятью
@ user726720: этот код может выполняться в течение сеанса отладчика, также он может выполняться без отладчика, но вероятность его выполнения в конфигурации выпуска близка к 0.
@SriramSakthivel: Я верю, что сборка мусора здесь не проблема, пожалуйста, исправьте меня, если я ошибаюсь (что я делаю большую часть времени, смеется), потому что код действительно выполняется. Так что таймер должен быть GC'ed после выполнения. Если это так, новый объект помещается в память при следующем printXML . Как я могу предотвратить образование новых объектов?
@Dennis: я пробовал это в конфигурации релиза и в производстве уже довольно давно. Я совершенно прав, это выполняется.
@ user726720: вы не можете предсказать, когда произойдет сборка мусора. Этот код может работать, но в конечном итоге он потерпит неудачу, потому что таймер будет собран до его истечения.
@ user726720 Мой комментарий не о проблеме с памятью. Честно говоря, нет информации, чтобы ответить на этот вопрос. Будет лучше, если вы напишите mvce, чтобы воспроизвести проблему. Мой комментарий выше говорит о том, что в вашем коде есть проблема, которая может быть неочевидной, которая работает сейчас, но это не значит, что она продолжит работать. Отослать это
Время цели использования таймера здесь состоит в том, чтобы задержать выполнение, и нет элегантного способа избавиться от него (что приводит к утечке памяти). Может быть, проще просто начать новый поток, который спит на х секунд. Или используйте один и тот же таймер, если два printXML не будут запущены одновременно.
@ Vince У меня одновременно работают 7 разных потоков FSW, которые могут вызывать printXML в разное время.
@ user726720 Как насчет создания новой темы? Смотрите мой отредактированный ответ.

Vince · Accepted Answer · 2014-11-06T04-34-00.000Z

System.Threading.Timer реализует IDisposable.

Оберните его внутри инструкции, чтобы убедиться, что она правильно установлена.

Если целью таймера является отсрочка выполнения, альтернативный способ может использовать новый поток и выполнить Thread.Sleep.

    public void printXML(XmlDocument doc)
    {
        var thread = new System.Threading.Thread(new System.Threading.ParameterizedThreadStart(DelayPrint));
        thread.Start(doc);
    }

    void DelayPrint(object param)
    {
        System.Threading.Thread.Sleep(15000);              
        XmlDocument doc = param as XmlDocument;
        // Do Work
    }

Если вы включите его в оператор using, обратный вызов не будет запущен, поскольку таймер уже настроен :(
Так что избавьтесь от него в обратном вызове.
@Sriram, вы правы, не используя здесь работу. Обратный звонок должен избавиться от него.
Это выглядит хорошим началом, изменив код, как указано выше. В данный момент тестируется память. Сообщит, если есть какие-либо проблемы.
Да, это работает правильно. Память сейчас под контролем. Спасибо