Что может объяснить более 5 000 000 экземпляров System.WeakReference в управляемой куче?

Question

Я выполнял нагрузочные тесты для производственного веб-приложения ASP.NET и вижу огромное количество ссылок System.Weak, созданных в куче. Примерно за 15 минут под нагрузкой объем управляемой кучи увеличился до 3 ГБ, и у меня есть около 5 000 000 ссылок на System.WeakReference. Выполнение принудительной сборки мусора для всех поколений не освобождает эти ссылки.

Я видел сообщения о вспомогательном классе __ENCLIST, который, если сборки скомпилированы в отладке, может создавать WeakReferences для всех создаваемых объектов, сначала я думал, что это проблема, но проверил, что все развернутые сборки встроены в выпуск.

Я использовал WinDbg для отладки процесса, вот несколько последних строк !dumpheap -stat

000007fef788e0c0    39253     18510000 System.Collections.Hashtable+bucket[]

00000000021bf120    94336    151023192      Free

000007fef7887e98     5959    189838752 System.Char[]

000007fef7874390   517429    589750224 System.Object[]

000007fef78865a0  1531190   1230824112 System.String

000007fef787dab8 51723338   1655146816 System.WeakReference

Как вы можете видеть, около 1,5 ГБ памяти было использовано этими System.WeakReferences.

Кто-нибудь знает, что могло бы создать все эти слабые ссылки?

Answer 1

Получается, что у меня была утечка System.WeakReference из-за динамического создания большого количества экземпляров System.Diagnostics.TraceSwitch, внутренне TraceSource / TraceSwitch выделяет WeakReference для нового TraceSource / TraceSwitch и помещает WeakReference в список. Хотя WeakReference позволяет собирать мусор в TraceSource / TraceSwitch, сама WeakReference никогда не будет освобождена, что приведет к утечке памяти.

Немного больше информации можно найти здесь

http://msdn.microsoft.com/en-us/library/system.diagnostics.tracesource(VS.80).aspx