Обнаружение утечек памяти в PerfView

Question

Я устраняю утечку памяти в службе Windows, которая используется в качестве службы интеграции.

По вызову doIntegration() я вижу, что использование памяти становится выше, чем до вызова, и увеличивается примерно на 0,5 МБ за вызов.

Я пытался использовать PerfView, чтобы определить, где могут быть утечки памяти.

Метод устранения неполадок:

1) Сделайте снимок кучи перед первым вызовом doIntegraion

2) Сделайте снимок кучи после вызова doIntegration

3) Сделайте шаг 2 несколько раз

4) Проверьте, какой метод / группа становится выше за звонок

5) Используйте diff на отдельных снимках, чтобы определить место утечки памяти.

Я вижу, что LIB mscorlib!RuntypeType - это метод / группа, которая увеличивается с каждым разом. Когда я пытаюсь проверить, что к нему относится, я получаю

• Закрепленные ручки
  • .NET Root
    • ROOT

И я не могу больше расширять дерево.

Когда я выбираю вид, RefTree я вижу еще кое-что.

• ROOT 100%
  • .NET ROOT 100%
    • Закрепленные ручки 70,6%
      • LIB mscorlib! RuntimeType 46%
      • LIB mscorlib! Отражение.... 13,4% ...
    • Статические переменные 30,7%
      • ns.ConfigurationSettings 59,5%
      • ns.Leaks.ConfigurationSettings -33,3%

Я сделал diff для нескольких снимков, и единственный метод / группа, которая увеличивает это закрепленные маркеры, и они относятся только к типам mscorlib.

У кого-нибудь еще была такая проблема?

Я думаю, что проблема может заключаться в сериализации из модели в XML с использованием XMLSerializer, но я не совсем уверен.

Кто-нибудь знает другой способ попытаться найти утечку памяти?

Спасибо:)

Answer 1

Ответ приходит довольно поздно. Но я был прав в своем предположении, что именно сериализатор увеличивал использование памяти за "doWork".

В XmlSerializer есть несколько "неприятных" конструкторов, которые фактически создают временную сборку для каждого инициатора, и они не будут собираться GC.

Я кэшировал различные XmlSerializer, которые использовали один из неприятных конструкторов, так что временная сборка создается только один раз.

Теперь утечки памяти не осталось.